Pablo , I might be interested in using your project as it gells with my own project (arwave.org - we want to establish a system for selectively shared geolocated content. Think collaboratively constructed and shared virtual worlds, not tied to any one company's server or even client). Is your project still maintained? (I mean, if we use it and Apache change the wave/client protocol a bit, will you make changes?)
We were bitten quite bad when Google abandoned wave, as we had working clients and demo's of our project back then on a few platforms. All stopped working a few months into the apache switch and we couldn't adapt due to the sever side being outside our skilllevel, or beyond the time investment our project members could contribute. ~~~ Thomas & Bertines online review show: http://randomreviewshow.com/index.html Try it! You might even feel ambivalent about it :) On 27 March 2015 at 14:11, Pablo Ojanguren <pablo...@gmail.com> wrote: > 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 > > > > > > > > > > > > > >
