For efficient, fully interactive clients, it is beneficial to have
their (OT) client-path wander off from the server path.
To do this, it is important that clients are able to recognize the
deltas they submitted themselves in the constant stream of
WaveletUpdates.
As far as I can tell, the only way to do this, is by looking at the
"version after application" field from the SubmitResponse for that
delta.
Because of this, it's very important that clients receive their
SubmitResponse first, before the WaveletUpdate for that change is
received.
Therefore, I was hoping this was in the protocol-specification, but I
couln't find this.
I know the Fedone server implementation currently handles this in the
right order, but it would be nice to have this somehow described as
mandatory somewhere.
Can anyone confirm that this indeed is part of the specification?
Or maybe my logic is flawed and there really is no need for this. In
that case please let me know.
On Sat, Jun 19, 2010 at 9:03 AM, Mathijs <bluescreen...@gmail.com> wrote: > Hi all,
> For efficient, fully interactive clients, it is beneficial to have > their (OT) client-path wander off from the server path. > To do this, it is important that clients are able to recognize the > deltas they submitted themselves in the constant stream of > WaveletUpdates.
Currently the FedOne server doesn't support fully interactive clients.
> Can anyone confirm that this indeed is part of the specification? > Or maybe my logic is flawed and there really is no need for this. In > that case please let me know.
There's really no need for this; as far as the spec is concerned a fully interactive client should follow the same logic as a federated server; in other words, never echoing back deltas at all. The FedOne server has a overly simple model for its clients; you are much better off looking at the logic used to respond to deltas from another server.
On Sun, Jun 20, 2010 at 2:14 PM, John Barstow <jbow...@amathaine.com> wrote: > On Sat, Jun 19, 2010 at 9:03 AM, Mathijs <bluescreen...@gmail.com> wrote: > > Hi all,
> > For efficient, fully interactive clients, it is beneficial to have > > their (OT) client-path wander off from the server path. > > To do this, it is important that clients are able to recognize the > > deltas they submitted themselves in the constant stream of > > WaveletUpdates.
> Currently the FedOne server doesn't support fully interactive clients.
FedOne *does* support fully interactive clients. I implemented one prior to the io2010 release. It is critical that the client know which of the updates corresponds to it's submitted delta in order to perform proper OT. I too had to rely on the current FedOne behavior where the update corresponding to a submit arrives after the submit response.
> > Can anyone confirm that this indeed is part of the specification? > > Or maybe my logic is flawed and there really is no need for this. In > > that case please let me know.
> There's really no need for this; as far as the spec is concerned a > fully interactive client should follow the same logic as a federated > server; in other words, never echoing back deltas at all. > The FedOne server has a overly simple model for its clients; you are > much better off looking at the logic used to respond to deltas from > another server.
No, there really is a need to know which update corresponds to the submit. Either the specification needs to state that the update (an all subsequent updates) will be delivered to the client after the submit response, or the protocol needs to be modified so that the client has a way of correlating an update to it's submitted delta. This correlation is critical to correct OT implementation.
On Mon, Jun 21, 2010 at 9:42 AM, Tad Glines <tad.gli...@gmail.com> wrote:
> No, there really is a need to know which update corresponds to the submit. > Either the specification needs to state that the update (an all subsequent > updates) will be delivered to the client after the submit response, or the > protocol needs to be modified so that the client has a way of correlating an > update to it's submitted delta. This correlation is critical to correct OT > implementation.
If the client is doing OT according to the spec it will never receive a update corresponding to a submitted delta. The FedOne client does not do OT, which is why there's stuff being echoed back to the client by its server. If both the client and server are tracking client state you run the risk of the states diverging, but I suppose that's the risk on building on top of the FedOne implementation.
Mind you I'm doing plenty of things besides tracking Wave development, so I've probably missed an update which completely demolishes my arguments.
The io2010 branch adds a channel id to the client/server spec. If this is used, a client shouldn't see updates for it's own submitted deltas. (The relevant code is in UserManager.java). As John noted, the old text client doesn't do OT, so it needs to get it's own updates back.
On Mon, Jun 21, 2010 at 09:31, John Barstow <jbow...@amathaine.com> wrote: > On Mon, Jun 21, 2010 at 9:42 AM, Tad Glines <tad.gli...@gmail.com> wrote:
>> No, there really is a need to know which update corresponds to the submit. >> Either the specification needs to state that the update (an all subsequent >> updates) will be delivered to the client after the submit response, or the >> protocol needs to be modified so that the client has a way of correlating an >> update to it's submitted delta. This correlation is critical to correct OT >> implementation.
> If the client is doing OT according to the spec it will never receive > a update corresponding to a submitted delta. The FedOne client does > not do OT, which is why there's stuff being echoed back to the client > by its server. If both the client and server are tracking client state > you run the risk of the states diverging, but I suppose that's the > risk on building on top of the FedOne implementation.
> Mind you I'm doing plenty of things besides tracking Wave development, > so I've probably missed an update which completely demolishes my > arguments.
> -- > You received this message because you are subscribed to the Google Groups "Wave Protocol" group. > To post to this group, send email to wave-protocol@googlegroups.com. > To unsubscribe from this group, send email to wave-protocol+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
