incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael MacFadden <>
Subject Re: Roadmap
Date Wed, 25 Mar 2015 13:22:32 GMT
I mainly agree with Yuri.  I personally believe that the first steps should be addressing the
part that make I hard for new developers to come in and help.

Build System… replacing obscure technologies… developer docs. Separation of UI from server…

On 3/25/15, 3:08 AM, "Dave Ball" <> wrote:

>It might be a little out of date, but:
>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:
>but is effectively an implementation detail of the current combined 
>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.
>[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:
>> phone: 203.293.8511
>> google+:
>> On Tue, Mar 24, 2015 at 4:32 PM, Thomas Wrobel <> wrote:
>>> On 24 March 2015 at 16:32, Dave Ball <> 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.

View raw message