The console client is an example where OT is only performed in the server. Once the console client has sent an operation to the server, it cannot perform or send any other operations until the server has transformed and applied the current operation. While the client doesn't have to perform OT, it still has to create deltas and apply deltas. And, it's interactivity is limited to the latency of one delta round-trip to the wavelet host and back. Not, that's not round trip to the server, but round trip to the wavelet host.
Instead of trying to eliminate OT from the protocol, a better approach (as others have mentioned) would be to provide an easy to use library/framework for performing common conversation operation, implemented in C/C++ with wrappers for most common languages, and example clients implemented in each. Given that, plus an easy to install server, the uptake would probably accelerate. -Tad On Sun, Aug 8, 2010 at 12:53 AM, 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%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/wave-protocol?hl=en. >> > > -- > 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%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- 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.
