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" <w...@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: jblos...@gmail.com >> phone: 203.293.8511 >> google+: google.com/+JohnBlossom >> >> On Tue, Mar 24, 2015 at 4:32 PM, Thomas Wrobel <darkfl...@gmail.com> wrote: >> >>> On 24 March 2015 at 16:32, Dave Ball <w...@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. >>> >
