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
