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?
