I fully agree with Thomas,
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. > I've made that in this Android project ( https://github.com/Zorbel/swell-android). Even I've ported client's GWT-specifc code to Android/Java instead of writing brand new code. > 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. > > Then I suggest to document this and follows Dave's comment. In particular, I will share (in a more visual way) how I move common+client code to Android in comming days. 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. > I've made that in this project (https://github.com/P2Pvalue/incubator-wave): GWT is used to generate a library accesible from normal JS. It exposes a generic way for using Wavelets. More info at http://p2pvalue.eu/blog/awakening-decentralised-real-time-collaboration (See section 4) > > > > ~~~ > Thomas & Bertines online review show: > http://randomreviewshow.com/index.html > Try it! You might even feel ambivalent about it :) > > On 27 March 2015 at 12:01, Patrick Coleman <patcole...@google.com> 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 <v...@ourproject.org> > > 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 https://reviews.apache.org/r/22776/ > . > > > > > > The review was closed. I patched here: > > > https://reviews.apache.org/r/28724/ > > > > > > > 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): > > > https://reviews.apache.org/r/31900/ > > > https://reviews.apache.org/r/31837/ > > > and: > > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201412.mbox/%3c5483011f.1030...@ourproject.org%3E > > > > > > > > >
