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: 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…
etc.




On 3/25/15, 3:08 AM, "Dave Ball" <wave@glark.co.uk> wrote:

>
>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