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 >> >>> >> >>> >> >>> >> > >> > >
