incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kaplanov <akapla...@gmail.com>
Subject Re: Roadmap
Date Tue, 24 Mar 2015 17:30:54 GMT
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 <pablojan@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 <wave@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".
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message