incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wrobel <>
Subject Re: Roadmap
Date Fri, 27 Mar 2015 11:14:47 GMT
You can split the client and sever without switching languages.
This is common in GWT projects.
You just have
- client (gwt java)
- sever (java)
- common (gwt-subset of java, but not using any gwt specific things)

Common can then be imported by any non-gwt (but still Java) clients, such
as Android.
People could also re-write gwt clients for other purpose's, or just to make
it cleaner.

For people wanting clients in completely different languages, the common
would need to be re-written. But that's always going to be the case. And Id
suggest having a clear isolation even in just Java makes this task vastly
easier and they can focus on just the bits that need converted to another
language. If its well written and documented (or even just well commented)
this should allow simple librarys people can import into their projects.

A third option is that GWT code can just be compiled to a javascript lib
which normal js can call. I haven't done that myself, but I've seen it
mentioned as a method for other projects.

Thomas & Bertines online review show:
Try it! You might even feel ambivalent about it :)

On 27 March 2015 at 12:01, Patrick Coleman <> wrote:

> Is there an implementable design anywhere for how a client/server split
> would work?
> It continually comes up as a blocking point preventing people from working
> on Wave, though I'm not familiar with plans for fixing it that maintain all
> required constraints.
> e.g. sharing business logic between client/server (and also any java
> client, like Android) was a large reason to use GWT originally.
> I don't believe there's a good way to drop that without introducing lots of
> incompatability issues -
> so the choices would be to switch to some other code-sharing system (e.g.
> nodeJS serverside like sharejs, although this doesn't feel much better),
> or stick with GWT client-side but provide a wrapper of the OT code that
> presents a cleaner JS API that people can write on top of.
> I'd recommend the latter, but for that to happen would require a chunk of
> work, and a good API design
> that actually addresses the desires of the people wanting to write
> client-side code against it.
> On 25 March 2015 at 21:29, Vicente J. Ruiz Jurado <>
> wrote:
> > El 25/03/15 a las 21:03, Andrew Kaplanov escribió:
> > >> I patched this review before
> > > I don't see your comments in the
> >
> > The review was closed. I patched here:
> >
> >
> > > Could you create Jira issue about the problem with shortcuts?
> >
> > Done.
> >
> > PS: Andrew, if you have some spare time, please comment my last
> > reviews/patchs (also related with this thread):
> >
> >
> > and:
> >
> >
> >
> >

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