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 <pratikparanj...@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 < > pratikparanj...@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 <jblos...@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" <w...@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 <w...@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 > >> >>> > >> >>> > >> >>> > >> > > >> > > > > >
