Well, actually I just checked and I found that Kiril already filed CCLA for Andrew.
On Sun, Apr 5, 2015 at 11:02 AM Yuri Z <vega...@gmail.com> wrote: > Sounds cool. > As already mentioned by Christian you can go ahead and add a link to > wiab.pro on demo servers page or maybe a new page for sponsors. Just make > sure to send the ICLA for companies. > > On Sun, Apr 5, 2015 at 10:47 AM Andrew Kaplanov <akapla...@gmail.com> > wrote: > >> Hi Yuri! >> >> I think current client-server protocol is poorly designed. >> - It mixes together getting of snapshots and opening of delta channels. >> This eliminates reconnection possibility. >> - All opened wavelet channels live in one protocol channel. >> This makes difficult separated control of channels and diagnostics. >> This and bugs in the code led to turbulences. >> >> I rewrote the protocol by using base design from >> http://www.waveprotocol.org/protocol/design-proposals/ >> clientserver-protocol. >> I have been extended this specification to support: >> - Diff operations from last viewed version. >> - Uploading of blips. >> - Raw data to optimize deserialization. >> >> I will be glad to commit new protocol if Kirill will agree. >> >> >> 2015-04-05 1:37 GMT+05:00 Yuri Z <vega...@gmail.com>: >> >> > 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? >> > >> >
