Can you clarify #2, what connection has the GWT rich text editor have with anything else? Surely as long as the server is Java, and the client is for the web (and thus JS), you would need GWT to code share, regardless of any rich text editing or lack of :? -- One option to allow non-gwt users is to have a gwt client without a UI with other JS implementations can call. Pablo Ojanguren on the mailing list mentioned this method and gave a link;
>> 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) The same project had a Android port; https://github.com/Zorbel/swell-android This solution might be worth looking into, seeing as someone has done it already. ~~~ Thomas & Bertines online review show: http://randomreviewshow.com/index.html Try it! You might even feel ambivalent about it :) On 4 April 2015 at 22:37, Yuri Z <vega...@gmail.com> wrote: > Hi > Let's us try to re-think the WIAB client-server protocol issue. > > From what I remember (please correct me if I am wrong) the client interacts > with server in four main ways: > 1. Requests a snapshot on opening a wave > 2. Sends deltas with updates > 3. Receives deltas with updates. > 4. Interacts directly with Search API. > The messages protocol used is Protocol Buffers and PST - Protocol String > Template, which is a custom written protobuff backed framework for > generating several versions of the same bean for Java/GWT etc.. which > allows easy serialization/deserialization. > Now, what are the main issues with this setup are: > 1. GWT - not an issue in itself, as I think it was a good decision at the > time and still the best way to re-use the same OT code on server and > client, but it requires GWT compilation and maintenance of GWT related > tools like the superdev and waveharness, requires certain version of > browsers for debugging, prevents us from moving to Java8 (and maybe Scala > for some server side parts). Also, while GWT is more or less main stream - > it is still adds another filter on potential contributors/adopters. > 2. Protobuff/PST based API while being efficient and sound decisions at the > time - now add more complexity and slower adoption. PST is basically a > whole framework that is written by Benjamin Kalman that is used AFAIK only > in WIAB. They also require additional step of source generation with C++ > based binary. Also, I think newer version of protobuff are not compatible > with PST. > 3. Tightly coupled Server/Client protocol - I think the protocol is fine > actually, what makes it hard to use is the point 2. > > So what can be possible solutions? We can: > 1. Solve somehow the issues from above - will require a lot of effort, and > probably will be never done. > 2. Give up on the GWT rich text editor and concentrate on Robot/Gadgets API > and Federation. > While, personally I would prefer solution #1, maybe it is more practical > and agile to cut it off and go with 2. > > Thoughts? >
