incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Ball <w...@glark.co.uk>
Subject Re: Roadmap
Date Wed, 25 Mar 2015 10:08:48 GMT

It might be a little out of date, but:
https://cwiki.apache.org/confluence/display/WAVE/Source+Code+Organization
might be a good start for anyone wanting to work on the client / server 
/ common split.  Anything with an x in both client and server columns 
would obviously be common! ;-)
[Pablo: I don't know if your work already covers this, and is mergable 
back into wave?]

John - long term aspirations are incredibly important, but Wave's 
problems at the moment aren't due to a lack of aspiration (there are 
plenty of great aspirations in the community, many of them shared by 
many of us).  My observation is that if wave is to survive at Apache we 
need a focus on manageable incremental improvements - getting more 
people involved in actually "doing".[1]

The client-server protocol is currently "defined" in this protobufs file:
https://git-wip-us.apache.org/repos/asf?p=incubator-wave.git;a=blob;f=src/org/waveprotocol/box/common/comms/waveclient-rpc.proto
but is effectively an implementation detail of the current combined 
codebase.

Making a split between client and server (and common) will expose this 
interface and make it more visible. Exposing the existing interface 
(without worrying too much about improving it) seems like an excellent 
initial step - and by making that interface more visible will hopefully 
make it more obvious how we can improve it iteratively.

Dave

[1] I'm as guilty as many in doing plenty of talking, but not actually 
contributing to the codebase or documentation in a meaningful way. Being 
conscious of this, I try to keep out of most of the "blue sky" 
discussions myself. I don't want my aspirations becoming a distraction 
to people that have the time to actually "do" the changes that are of 
interest to them.

On 25/03/15 00:56, John Blossom wrote:
> Liking what I am hearing.
>
> My ten cents:
>
> client/server/common model is good for libraries, yes, but need
> well-defined client APIs to allow multiple apps to access common data
> stores. Otherwise you get more balkanisation and the data model never takes
> off.
>
> federation required, preferably in a way that will support sync/async
> collaboration and store-forward data models.
>
> Would like to see Wave 3.0 ideas considered.
>
> All the best,
>
> John Blossom
>
> email: jblossom@gmail.com
> phone: 203.293.8511
> google+: google.com/+JohnBlossom
>
> On Tue, Mar 24, 2015 at 4:32 PM, Thomas Wrobel <darkflame@gmail.com> wrote:
>
>> On 24 March 2015 at 16:32, Dave Ball <wave@glark.co.uk> wrote:
>>
>>>>   Might it be better to have three "parts"?
>>>   - common
>>>   - server
>>>   - client
>>>
>>> Common would contain the document and concurrency model etc. Client and
>>> Server would both depend on Common. Common would compile to JS for the
>>> Client, but Server would depend directly on Common so wouldn't need to
>>> depend on the compiled javascript.
>>>
>>>
>> +1
>> I think this would be the best way to maintain compatibility between
>> client(s) and sever(s). Downside is people making non-Java clients (or
>> non-JS via GWT) would need their own common implementation.
>> But it wouldnt be any worse then now.
>>


Mime
View raw message