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