David recently described the current c/s protocol to me when I was
trying to understand it;
"The messages are JSON, and their structure is defined by some protos, and
enveloped as (see WaveWebSocketClient$MessageWrapper):
{ sequenceNumber: <unused I think>, messageType: <message class name>,
message: <object> }.
WaveWebSocketClient essentially defines the client side of the protocol, and
it's very trivial. Over a bidirectional stream (websocket), the client
sends an open request (ProtocolOpenRequest), some number of submit requests
(ProtocolSubmitRequest), and then closes the web socket. After the open
request, the client receives a constant stream of ProtocolWaveletUpdates,
containing either wavelet snapshots or wavelet deltas, interleaved with
ProtocolSubmitResponses, which contain the success/failure of the client's
own submits. Details about those particular messages can be found in
waveclient-rpc.proto, but the previous sentence above covers almost the
entire protocol, and it's expressed quite simply in the code. The bit I
left out is the authentication messages, which I never looked into, but the
code looks pretty straightforward."
However, there is some problems with this current protocol, hence the
new one (which you are correct, hasn't been implemented yet).
-Thomas
On 21 July 2011 01:38, Eduardo Garcia Lopez <[email protected]> wrote:
> Hi Thomas,
>
> well, the diagram is there just to raise (and try to get answer to) this
> kind of questions. I am not sure if the client server protocol described in
> that document you pointed is already implemented. Anyway, reading this other
> document "http://www.waveprotocol.org/code/wave-model-code-walk"; it seems
> clear that the communication with the client side is done from the model,
> specifically in the "org.webprotocol.wave.model.conversation" package. How
> the events are propagated to the Undercurrent GWT client is something I
> still don't know, that is why I put that black box named "Events Listener"
> between the model and the client, that somehow communicates with the GWT
> side (although something I know is that this communication is not via GWT
> RPC).
> I have read about the WaveData API (distributed as part of the Robots API),
> it seems it was the originally proposed mechanism to communicate with
> clients (not only with robots) when Wave was a Google product, but I don't
> know how/if this has changed.
>
> Thanks,
>
> Eduardo.
>
>
> On Thu, Jul 21, 2011 at 12:56 AM, Thomas Wrobel <[email protected]> wrote:
>
>> Ive always thought modularisation is a very good idea, but in that
>> diagram I'm a little confused as it shows the GWT client communicating
>> with the server via the "wave-protocol" - I'm not sure this is right?
>> The wave federation protocol is for server<>server, the client<>server
>> uses (and will use) something different;
>>
>> http://www.waveprotocol.org/protocol/design-proposals/clientserver-protocol
>>
>> I think I heard this called the "simple data protocol" at one point,
>> but I dont think it is named.
>>
>> Or are you proposing the s<>s and c<>s communication should basically
>> be the same? (or, one as a subset of the other).
>>
>> On 21 July 2011 00:41, Yuri Z <[email protected]> wrote:
>> > Regarding modularization - there were talks about using Maven to manage
>> WIAB
>> > dependencies and introduce better modularization of the code. It might be
>> of
>> > interest to you -
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201105.mbox/%[email protected]%3E#archives
>> >
>> > 2011/7/21 Michael Lilly <[email protected]>
>> >
>> >> Hi, code-laboration is working on a project that uses WIAB as the core
>> >> framework, but with modifications to the UI and the UX. We saw that
>> there
>> >> were just some talks about modularisation, and had actually been
>> thinking
>> >> of
>> >> the same thing for the past several days. We had talked to Yuri the
>> other
>> >> day about this, and now feel it is at a point where we can share our
>> >> interests with everyone.
>> >>
>> >> Because we will be doing so many modifications, it would be great for
>> WIAB
>> >> to be more modular to allow for us, and potentially other forks of the
>> WIAB
>> >> project to work in parallel. We have come up with a list of things that
>> we
>> >> personally feel would be a great help to modularize. the document is
>> posted
>> >> on Google Docs. This document is a rough draft of what would be changed,
>> >> and
>> >> is fully open to comments of the dev community. Here is the Doc:
>> >>
>> >>
>> http://www.google.com/url?sa=D&q=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fpub%3Fid%3D1V4PaVPMKPdt0-BugDxmy0dfvmf9UJh-MvLDRBd-vk_Q
>> >>
>> >> Also, we have been creating documentation related to WIAB, and would
>> like
>> >> to
>> >> share them with the community. I see there is a wiki on the Apache
>> >> incubator
>> >> website, but with no content. So I am wondering where the proper place
>> >> would
>> >> be to add this content.
>> >>
>> >> We do not have much on our websites currently, but you are free to check
>> it
>> >> out. Our two websites are codelaboration.com and twykin.com
>> >>
>> >
>>
>
>
>
> --
> Eduardo G.
> http://www.stream18.com
>
