incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Blossom - Shore Communications Inc." <jblos...@shore.com>
Subject Re: Moving Wave Forward
Date Wed, 29 May 2013 14:49:49 GMT
Pratik,

Thanks so much for your very thoughtful comments. Federation is definitely
at the core of Wave, and makes it potentially powerful for people who want
to view waves in different environments. I haven't looked at the protocol
as defined in detail for a while, so I will refresh myself on that, but my
impression is that although the basics are there, packaging and services
could be refined to make it a simpler and more powerful tool - especially
if client/server stack can be implemented on a person's mobile device in
HTML5. I am trying to encourage other developers to join this conversation
who may have some insights along these lines that may be useful.

You're right about the server code, it's not so important that it be
deprecated along with the client code, assuming that it's been properly
teased apart, though I am hopeful that the code base as a whole can be
reviewed for efficiency and scalability. Even on Rizzoma, which has worked
hard on performance issues, there seems to be a fair amount of lagginess.
Perhaps with a modern client code base the Web servers will be able to
change more incrementally. With that in mind, I have adjusted the deck to
indicate the possibility of deprecating the Java client code specifically.
There is only so much that can change at first, to be sure. On the client
side, though, I feel pretty strongly that unless we can use the most modern
techniques to put Wave clients right on the cutting edge of mobile Web apps
and services, it will not get the adoption that it will require to be a
successful project. Wave can be, and should be, more than a proof of
concept platform. Wave should be one of the most powerful and effective
tools for collaboration and knowledge-building available, with many, many
powerful UIs and applets.

You are right about developer interest, which is why I have presented this
deck - to give developers a sense of how working on Wave can put them right
at the cutting edge of some of the most important things happening on the
Web. In essence, Wave WAS the cutting edge back on 2008-9, now that the
edge has moved, we need to reposition Wave to take advantage of it - which
it certainly can, given many of its still-unique qualities. I acknowledge
that this will be harder to do without a major backer like Google, but this
is where the process starts to define the backing. Google is not the only
company in the world that needs to have a unique advantage via Web
communications. If the Apache community developers are excited about where
this could head, then that will be a factor in helping us to secure the
backing to enable people to do more work and more powerful work on Wave.

Many thanks,

John

On Wed, May 29, 2013 at 4:20 AM, 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