Today we are trying to do Wave faster. This problem was trying to decide Google, but did not. I believe that we can do it.
2015-03-24 22:14 GMT+05:00 Pablo Ojanguren <pablo...@gmail.com>: > From a technical perspective I mostly agree with Yuri's roadmap, priorities > apart and wiab.pro improvements are awesome. > > But I think the big question is what can we do first to get new > contributors and foster the community? Do we know what developers want from > Wave? > > For example, personally I am interested on building new collaborative apps > with Wave's technology. But I don't need the conversation model and the > current GWT client app. So I am building my own API on top of Wave. > > So the question would be, what do you expect/want/need from Wave as > developer? the answer can lead technical tasks afterwards. > > > > > 2015-03-24 16:32 GMT+01:00 Dave Ball <w...@glark.co.uk>: > > > On 24/03/15 13:49, Yuri Z wrote: > > > >> 3. Re-think how we should solve the tight coupling/great complexity of > >> client-server protocol. Maybe we should split the Wiab project into two > >> parts server and client - where server will depend on compiled > javascript > >> client. > >> > > 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. > > > > I'm not particularly familiar with the codebase, but I think there is > > already an implicit assumption of these three parts - although at the > > moment they are somewhat(!) interwoven in the same codebase. > > > > Dave > > > > ps - separating the document model and the concurrency model might also > be > > beneficial, but that looks like a bigger piece of work - and could always > > be "stage 2". > > >
