incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pratik Paranjape <pratikparanj...@gmail.com>
Subject Re: Moving Wave Forward
Date Wed, 29 May 2013 08:37:51 GMT
p.s. I was able to setup (server-to-server) federation long back, I think a
few months after Google IO10, it was not easy, but it had worked. Back then
there were quite a few guides available.


On Wed, May 29, 2013 at 1:50 PM, Pratik Paranjape <pratikparanjape@gmail.com
> wrote:

> Hello John,
>
> It was good to see the presentation, thank you for putting it out.
> Ambitious but tempting.
>
> I would like to comment and emphasize on couple of things others have
> rightly said before:
>
> 1) Federation as defined in Wave-protocol is collaboration among the
> servers of different organizations to exchange the wave/wavelets e.g. Wave
> server under domain acmedotcom communicating with wave server under
> zuludotcom, in real time. This has always been an implemented feature of
> the wave code base and was one of the first features released by the Google
> team. Protocol evolution was left open ended for changing requirements
> depending on adoption.
>
> If I understood correctly, you are using the word federation as in
> allowing different devices communicating with each other. This feature is
> really a byproduct of good server design. All communication WILL have to go
> through server. As long as the server endpoints and data models are well
> defined, its possible for anyone to write a client and represent the
> fetched data in any desired format. In other words, Federation at its
> core : Any device can federate with any other, is actually adoption
> dependent and will not require special design for Wave. Encouraging
> development of host of such clients. possibly providing samples, can
> definitely be a point.
>
> 2) Even though there are several spots for serious improvements in wave
> code ( mostly because of the new technologies and current Browser landscape
> especially atuned to a product like wave: new editors, reactive servers
> like node and play!, faster databases like mongo and redis), it will be
> unwise to throw away the code and start from scratch (Reference:
> Deprecating Java Code in slides ). Its not a small project by any
> consideration and as Michael pointed out, unless there is sudden inflow of
> a number of developers, its not going to be easy to make big changes even
> for a commercial entity. Best way would be to put up issues one by one and
> go through solving them (as the team is doing currently). Re-design and new
> architecture, which is undeniably necessary, will have to evolve through
> this path.
>
> Hello Michael,
>
> 2)
>> The current codebase is largely a proof of concept.  It has some
>> potential, but I think most of us would agree that some time spent
>> re-architecting how we want things to work and morphing the code base into
>> that (or rewriting it) would be in the projects best interests.  Again if
>> we have a roadmap and people who feel strongly about working on those
>> areas, we can divide and concours.
>
>
>
> Thanks for acknowledging
> this
> .
> Coming from someone who has been involved with Wave since very early, it
> makes the point official. It will indeed first step to prepare a road map
> and get agreement on a list of necessary changes. I had posted a list in
> one of the earlier messages.
> Of course as Upayavira has pointed out, everything of it will depend on
> the developer interest, which is not up to the same level as proposed
> changes at this moment.
>
> Wishing best for Wave.
>
> Pratik Paranjape
>
>
> On Wed, May 29, 2013 at 9:10 AM, John Blossom <jblossom@gmail.com> wrote:
>
>> Dave,
>>
>> Thanks, I think that we're on the same page. No doubt that Wave federation
>> holds out tremendous promise. Hopefully the Apache community can move
>> towards deciding how they'd like to progress towards more advanced goals.
>> I
>> welcome any and all suggestions to that end.
>>
>> Best,
>> John
>> On May 28, 2013 11:08 PM, "Dave" <wave@glark.co.uk> wrote:
>>
>> > John,
>> >
>> > Sorry, I wasn't trying to say that wiab provides the mobile client that
>> > you are looking for, just that the wave federation concepts and their
>> > implementation in the wiab server are likely to be a good fit for your
>> > usecases. You suggested that the federation paradigms needed a complete
>> > re-think for a "mobile-first world", and my understanding is that this
>> > isn't the case.
>> >
>> > So while federation and the "server" component sound like a reasonable
>> > fit, the mobile _client_  (supporting off-line access etc.) doesn't
>> exist
>> > yet.
>> >
>> > Over the years there have been a few discussions about formalising the
>> > client/server protocols within wiab - but so far there hasn't been the
>> > manpower to implement it.
>> >
>> >
>> > Dave
>> >
>> >
>> > On 29/05/13 03:30, John Blossom wrote:
>> >
>> >> Dave,
>> >>
>> >> I think that you've captured much of both the paradigm and the paradox.
>> >> Wave could - and should - be able to do these things, but in the
>> existing
>> >> kit you really cannot do it for many of these points, and where it
>> does do
>> >> it one cannot say that the mobile-Web interface is elegant. In none of
>> the
>> >> cases, AFAIK, does it deal with the case of people initiating new Waves
>> >> offline on a mobile device and adding in applets or shifting to
>> different
>> >> UIs for the same wave. Also not covered in the mobile client is the
>> >> potential for peer-to-peer mobile Wave communication. This will be of
>> >> particular importance to "next billion online people" markets. I agree
>> >> that
>> >> with connectivity, the client may communicate to a primary server for
>> >> further downstream federation for specific waves (other servers for
>> other
>> >> waves, if done properly, if there is not node-to-node credentials, as
>> in
>> >> company X only wants to communicate with mobile clients directly). The
>> >> email analogy is certainly clear, but Wave federation and client-server
>> >> functions need to focus first on getting waves to support multiple Wave
>> >> UIs, so that there will be compelling reasons to build out federation
>> for
>> >> email support, via presentation layer adapters.
>> >>
>> >> So if the client/server break is/can be formalised in code, then we can
>> >> move towards a mobile-capable HTML5/JS client which is efficient,
>> robust,
>> >> supports multiple UIs on top of the same data sets, and which can have
>> >> offline, server-like functions which can enable peer-to-peer
>> federation.
>> >>
>> >> I may not be completely up to speed on the current architecture's
>> status,
>> >> but so far the responses that I am receiving seem to confirm where the
>> >> architecture needs to adapt to modern requirements and performance
>> >> expectations. Hopefully we can all work together to address the huge
>> >> opportunities that those requirements present.
>> >>
>> >> Thanks,
>> >>
>> >> John
>> >>
>> >> On Tue, May 28, 2013 at 9:54 PM, Dave <wave@glark.co.uk> wrote:
>> >>
>> >>  John,
>> >>>
>> >>> I'm not a committer, but I have some familiarity with the wave stack.
>> >>>
>> >>>
>> >>> On 29/05/13 01:23, John Blossom wrote:
>> >>>
>> >>>  People need their waves to live on their mobile devices, not just on
>> >>>> cloud Web servers. After all, email provides local mobile offline
>> >>>> capabilities.
>> >>>>
>> >>>>  I think you might not be 100% up to speed with some of the Wave
>> >>> architecture. In an email world, people have mobile off-line access,
>> but
>> >>> they still use email servers.  The email server often has the
>> definitive
>> >>> copy of their email [i.e. imap], and mobile just retains a cached
>> copy.
>> >>> In
>> >>> a mobile world, you still need a permanent server address to deliver
>> mail
>> >>> to, or send it through.
>> >>>
>> >>> This is the same with wave:
>> >>>
>> >>> client <---c---> server <---f---> server <---c--->
client
>> >>>
>> >>> The federation protocol [f] sits between the two servers, and to
>> support
>> >>> mobile clients you would expect those clients to:
>> >>>   - maintain cached waves
>> >>>   - allow off-line access to those waves
>> >>>   - allow off-line changes to those waves
>> >>>   - propagate changes in real-time where possible
>> >>>
>> >>> In theory a wave server can support different clients. Unfortunately
>> in
>> >>> the current wiab codebase, there is only one client - which is the
>> >>> bundled
>> >>> web-client. The current code base does sort-of have the logical
>> >>> client/server separation as outlined above (though some code is shared
>> >>> between the server and the client), but there isn't a formally defined
>> >>> client protocol [c], or separation of the web-client.
>> >>>
>> >>> So in a broad sense, to support mobile one would need to:
>> >>>   - formalise the client-server protocol [c]
>> >>>   - implement that in WIAB (ideally allowing Server and web-client to
>> be
>> >>> deployed separately)
>> >>>   - implement your mobile clients.
>> >>>
>> >>> Any mobile client would still communicate through a server (as email
>> does
>> >>> today) allowing (among other things) third parties to interact with
>> waves
>> >>> whilst _I_ am offline.
>> >>>
>> >>>
>> >>>   So if you are considering the possibility of a mobile-first world,
>> you
>> >>>
>> >>>> really do need to
>> >>>> rethink existing Wave federation paradigms seriously.
>> >>>>
>> >>>>  There may be some corner cases which would need tweaking, but my
>> >>> understanding is that the core wave federation paradigms / protocol
>> (and
>> >>> the wiab federation implementation) suit mobile very well. They were
>> >>> explicitly designed to support real-time when online, and disconnected
>> >>> access when offline.
>> >>>
>> >>> Someone please correct anything I've got wrong!
>> >>>
>> >>> Dave
>> >>>
>> >>>
>> >>>
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message