Michael, Thanks for the positive feedback. If we can articulate the vision with a little more refined materials and get some indication that Apache would welcome a well funded initiative to promote Wave as a cutting edge platform, then I think that I'd be interested in helping to make that happen. I look forward to reviewing your comments.
Best, John On May 28, 2013 11:00 PM, "Michael MacFadden" <michael.macfad...@gmail.com> wrote: > John, > > Thanks for your thought and interest in Wave in general. I think there > are a few thoughts I can add. > > 1) > What you are interested in doing is key to wave's success. One issue that > we have had is NOT putting out a coherent roadmap for developers and users > to understand. Providing a VISION is critical to gaining momentum. > > 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. > > 3) > In regard to setting up a non-profit or donation pool. It think that is > fine, it is just outside the scope of apache. So for example I work for a > company that may invest our own time and money to help develop wave. As > such we would simply sign a corporate contributor agreement. The fact > that a developer might be getting paid to work on the code base is > irrelevant to apache as long as the copy right and ip for the code is > fully and clearly transferred to apache. > > A non-profit can fund developers on donations if they like. There just > has to be some recognition that any work done on the apache project is > owned by the apache foundation. I can't speak to the exact legal > requirements, but it is workable. > > 4) > I think we can welcome people like you into the Apache Wave group. We are > a very small but open community. We need help, of any kind. A large > group of people who are serious about pushing wave forward, can, if they > are committed, become a driving force within the Apache Wave community. > > 5) > In reagards to the brief, I will add comments directly to the > presentation. But I agree that we should make this public. > > Thanks > > ~Michael > > On 5/28/13 7:30 PM, "John Blossom" <jblos...@gmail.com> 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 > >> > >> > > >
