incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yuri Z <vega...@gmail.com>
Subject Re: Re-thinking Client-Server protocol
Date Sun, 05 Apr 2015 08:02:15 GMT
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 <akaplanov@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 <vega113@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?
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message