Re: obby

[Phil Hagelberg <phil@hagelb.org>]

Richard M Stallman <rms@gnu.org> writes:

>     I had planned to revisit the problem once the new implementation of the
>     obby protocol and client (now called Infinote) had been released. But
>     implementing inclusion transformation is very difficult.
>
> Can you tell us more about this problem?

The first part involves keeping a lot of state. Every edit that could be
re-applied (by someone else sending a conflicting edit to the same
portion of the document before yours reached the server) would need to
be stored along with some metadata. (It may be possible to tie into
Emacs' existing undo mechanism for this part if you were able to add
some metadata to each action.)

But then if you are notified of a conflict, you need to un-apply your
changes, apply the canonical ones you received from the server, and
transform your edits so they apply cleanly. This is pretty
complicated. It's analogous to a rebase operation if you're familiar
with the concept from some distributed version control systems, only it
applies on the document level rather than across a whole
repository. There are more edge cases that result when re-applied edits
need to be split to ensure consistency; I am not sure I understand these
fully.

Details about the transformation algorithm are available on the obby wiki:

  http://gobby.0x539.de/trac/wiki/AnnotatedObbySession

>     By the way, this is a textbook case for why we would want to support
>     dynamic linking. The reference implementation of the Infinote protocol,
>     libinfinote, is released under the LGPL, so it would save a great deal
>     of effort to be able to use that rather than creating a new,
>     independent, under-manned implementation from scratch.
>
> We could link with it non-dynamically too.

With non-dynamic linking it's still possible, but such a project would
be forced to move more slowly since recompiling would be necessary for
every user. If I were able to write something that could use libobby and
distribute it to others without making them patch and recompile Emacs, I
would be much more likely to start such a project. Every so often I read
about extensions to Emacs that require a recompile, but I've never
actually used one since it's more complicated to get started with them;
I just don't bother.

If the project were worked on by core Emacs developers in the official
repository, this would be less of an issue since people are more
familiar with just pulling updates and using that. But it seems
inconsiderate to the community to say something is not important just
because it doesn't bother the core developers.

> I don't understand the structure of the situation.  Did you
> reimplement the same thing in Lisp?

That's correct; I implemented a subset of the protocol in Lisp. But
since it was not documented at the time, I did not implement
transformations, just a naieve edit scheme that assumed there would
never be conflicts. So it worked reasonably well as long as you were on
a local network and latencies were low, but over the Internet you would
see inconsistencies.

-Phil