deltaOk buglet?

1 view
Skip to first unread message

Joe Walker

unread,
Jul 31, 2009, 8:33:24 AM7/31/09
to mobw...@googlegroups.com

mobwrite.shareObj.prototype.deltaOk is a global setting, however I think it should perhaps be per shareHandler shouldn't it? When you share a 2nd element, that element it starts off unsynced, where as deltaOk might be true because the 1st element has synced.
Maybe I'm not understanding it properly...

Joe.

Joe Walker

unread,
Jul 31, 2009, 8:55:24 AM7/31/09
to mobw...@googlegroups.com

Scratch that. The clue is in the 'prototype' word. Doh!

The issue was that patchClientText was doing a check to see if (oldClientText != result[0]) and skipping the update if there was nothing to change. This was causing our view of "are we in sync" to be out of sync with mobwrite's view of "are we in sync".

Joe.

Mikey

unread,
Aug 1, 2009, 2:07:56 PM8/1/09
to MobWrite
Hello joe

Altho this is a little off this topic. I just wanted to say I also had
a problem with two objects connecting to the same sync and I thought
id share how I deal with it.

The problem is actually more complicated aswell. Gedit (the client I'm
writing mobwrite for) is single threaded and due to its design does
not allow built in methods of multithreading (gobject threads). It
actually segfaults gedit if u try.

On top of that.. the data I'm sharing can (and two of them are) be
complex objects.

One of them is a gtk.Document. even though this simply contains plain
text which mobwrite can handle, to apply changes is complex and simply
setting its text will not work.

The other object is actually structured data inside a "dict" object.
This requires a special function to convert its contents to plaintext
and another to write data to the object.

So the best solution was to create the shareobj getText applyPatch and
applyRaw callbacks. If the 'clientText' is a string.. do the default
actions. Otherwise call the callbacks with the information needed.

This ment I could run all the getText callbacks and set the clientText
if needed. Create a fork() with only the shared objects needed. And
then run the callbacks once the data is returned.

if I have two documents pointing to one sync object I update both in
the applyPatch or applyRaw callbacks. Tho not "technically correct" as
each document maybe different. The user can only edit one document at
a time so the risk of collisions is minor. Enforcing the two documents
are equal is more efficient than syncing with two shares.

Mikey
Reply all
Reply to author
Forward
0 new messages