incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pablo Ojanguren <pablo...@gmail.com>
Subject Re: Roadmap
Date Fri, 27 Mar 2015 13:11:55 GMT
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 <patcoleman@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 <vjrj@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.1030805@ourproject.org%3E
> > >
> > >
> >
>

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