Hi Joel.
I'll try, other will correct me or complement this info,
wave-vs.net implements its own editor and editor wrapper on visual
studio that is a 'fat client', what means, in general,
latency between client and server could be high depending on usage
scenario.
Wave specification tells 'only one delta from client can be waiting to
be ACKed (accepted) by server' AND
if client continue generating deltas (editing operations on local
document), the are locally accepted and must be enqueued to be send to
Server one by one.
Developing above requirement you will find latency between clients and
server, (even when there are only two active participants submitting
changes to Server), can cause one client A to submit N changes,
(N>1), while other client B has submit only one, and both of them have
pending deltas to send to Server
Side effects on client B when server process sent delta is client B
received deltas from client A, (already accepted by server), that have
been alredy applied on client A and Server Document Space and need to
be applied to your local copy together with your local changes, (not
yet accepted by server)
Here you have two options:
a) Transform all received deltas from Server against all your enqueued
deltas and apply changes to Document linearly (this is the famous OT
you can see on papers), and continue sending enqueued deltas to server
b) Transform all enqueued deltas against all new received from Server
deltas, recoved editor document to the state before first delta was
out-of-sync and begin to apply deltas since this state to the end, and
continue sending enqueued deltas to server
This operation is a loop while ( EnqueuedDeltasToSend.Count > 1 )
To avoid to have OT on client you must implement your software in a
very strange way:
- When a change occurs on document BEFORE apply on editor visual
buffer:
1) Client only send SYNC Operations to server trying to gain a
lock on server to modify document
2) Client send document delta
3) Delta is forward to all participants
4) All participants say OK
5) Lock is automaticaly free by server.
This is completely useless, any network with high latency like >200ms
avg by operation will only permit 5 changes document by second.
So 5 people typing in a document will only be able to do 1 keystroke
by second.... useless :)
About
>>Are there circumstances and/or potential implementations
>>where OT would only have to be applied in one or the other (presumably the
>>server)? If so, that would reduce the overhead necessary for future code
>>releases.
To be able to do this I guess server or client need to know all
document states and divergence from all clients, in this way it will
send the right already-transformed delta to all clients, I don't think
this is possible, probably you need to fall into sync client-server
operations that is not reliable.
So I think real problem is not OT itself, is how to treat document
divergence between clients and server.
Hope this helps.
Jesus Salas
wave-vs.net
On 8 ago, 09:53, Joel Dietz <[email protected]> wrote:
> On a technical note, I've never quite understood why OT needs to be
> performed on both the server and client, except the presumed latency between
> one and the other. Are there circumstances and/or potential implementations
> where OT would only have to be applied in one or the other (presumably the
> server)? If so, that would reduce the overhead necessary for future code
> releases.
>
> If anyone could explain that to me I'd much appreciated it.
>
>
>
> On Sat, Aug 7, 2010 at 10:51 PM, Joseph Gentle <[email protected]> wrote:
> > On Sat, Aug 7, 2010 at 5:13 PM, Brett Morgan <[email protected]>wrote:
>
> >> Patrick,
>
> >> OT and version control systems serve very different masters. By that I
> >> mean you wouldn't want to use the merge system of version control systems
> >> for Wave, just as you would not want to use OT for managing source code
> >> history.
>
> >> The reason is simple, to steal a line from one of the Wave team, OT is too
> >> good. OT's merge never fails.
>
> >> In version control systems you, as a user, rely on the merge failing to
> >> highlight areas that need human intervention. In wave we don't want humans
> >> to have to constantly be involved in handling the real time merge of the
> >> disparate change streams.
>
> >> brett
>
> > This is one of the fantastic use cases of having different OT semantics for
> > different types of data.
>
> > - For code editing, I want the current wave OT algorithm
> > - For code merging (ie, merge my changes with yours) I want edits on close
> > regions of the document to create conflict markers.
>
> > (I think) it should be a reasonably easy change.
>
> > -J
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Wave Protocol" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<wave-protocol%2bunsubscr...@googÂlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/wave-protocol?hl=en.- Ocultar texto de la
> >cita -
>
> - Mostrar texto de la cita -
--
You received this message because you are subscribed to the Google Groups "Wave
Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
