incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wrobel <darkfl...@gmail.com>
Subject Re: Moving Wave Forward
Date Wed, 29 May 2013 10:43:09 GMT
Would it be correct to say the steps towards multiple clients (both desktop
and mobile) would be:

1. Separate out the server and client code we have atm. (hard/long job?)
2. Formalize a working protocol between the client and server.
3. Document this protocol nicely.
4. Implement this protocol into a library so it can be used easily by
anyone making a client, also making updating those
clients easier if the protocol changes. (just put in a newer version of the
library).
5 (option) Ports of that library to a few languages.
6. Hopefully mobile and alternative clients appear using these libs.
?

The first parts would need to be done by Apache, but possibly 4/5/6 can all
be left to 3rd parties.
-Thomas

On 29 May 2013 10:37, Pratik Paranjape <pratikparanjape@gmail.com> wrote:

> 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