incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael MacFadden <michael.macfad...@gmail.com>
Subject Re: Moving Wave Forward
Date Wed, 29 May 2013 02:59:32 GMT
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" <jblossom@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 <wave@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
>>
>>



Mime
View raw message