i think best way for wave is native mobile clients.
On Wed, May 29, 2013 at 1:43 PM, Thomas Wrobel <[email protected]> wrote: > 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 <[email protected]> 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 < > > [email protected] > > > 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 <[email protected]> > > 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" <[email protected]> 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 <[email protected]> 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 > > >> >>> > > >> >>> > > >> >>> > > >> > > > >> > > > > > > > > > -- ahmet raşit demirkan SeyRah bilişim www.seyrah.com +902125217678
