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? > > >
