Il 03/01/2012 10:08, Abdelrazak Younes ha scritto:
One general comment:
IMO we should have a dedicated proxy server program for this stuff,
i.e. remove all server related code from your patch and put that in a
new daemon tool. This means that this tool could be launched anywhere
on the internet and the LyX instances don't have to know their
respective IP addresses, only the server one.
I would call this new tool LPS that is LyX Proxy Server. No Gui in
there, just a TCP server that will proxy the lyx commands between the
connected LyX instances. We would need a small protocol to set client
ids, to retrieve list of connected clients, etc. After that, maybe we
could switch to a standard protocol as suggested by Rob.
I agree, absolutely. For now, I wanted a fast prototype so it's easy to
connect directly from LyX to LyX. Actually, the full-fledged feature
would involve:
-) in LyX, having a collaboration GUI panel, showing the status of the
connection with the server, as well as which users are on-line,
similarly to Skype or Pidgin or others;
-) the panel might allow you to start a LyX-enhanced chat, as well as
collaborative editing, allowing you to choose among the buffers that
users are sharing on-line;
-) a server which, additionally to do the dumb job of forwarding
messages among connected users, should also be integrated with a
web-based users registration facility.
Back to the dark part of the feature, i.e., collisions: if 2 users try
to edit the same paragraph, what would you do ? (note that, as of now,
you may have a user adding at the beginning of a statement and the other
one adding to the end -- the mess comes only if their cursors and edits
overlap/cross each other) I wouldn't mind too much if the paragraph
contents ends up to be "weird", i.e., non-necessarily corresponding to a
perfectly serial intermixing of the editing actions (that means users
didn't sync before editing). What I'm concerned about is how to detect
this kind of scenarios and fix them so that the 2 (or more) instances
end-up with a consistent copy of the modified document.
One way might be to exchange hash values re-computed over the affected
paragraphs at each modification (e.g., build a hash tree over the
document hierarchy) and, if any deviation is detected, then the clients
fetch from the server a clean copy of the conflicting paragraph(s) only.
Bye,
T.