On Wed, May 1, 2013 at 6:23 AM, Tommaso Cucinotta <tomm...@lyx.org> wrote: > You could, but I'm not sure about what advantage you get. LyX keeps in > memory a structured graph of C++ objects, not their serialized version. > If you send a serialized paragraph, then you have to de-serialize it > replacing the corresponding C++ object(s) on the other side, but a > paragraph may be veeeeery long. Instead, we might want to send just > the editing action, that normally should be smaller to be sent. >
What I'm proposing is basically keeping two different layers of representation of the document at the same time. While redundant, it would simplify several things due to code reuse and a simple protocol for exchanging edits. The first layer is a textual representation (the LyX format itself) and the other is the internal C++ objects structure: these can be translated into one another. The LFUNs are to be processed locally by existing code (modifying internal objects) and when a user wants do dispatch his edits, he should serialize (using export to file routines) the *modified* objects and generate a *diff* of the string with the previous revision (so small edits should be cheap). The user on the other side would get this diff and apply to its textual representation, then deserialize the affected snippets of text, replacing appropriate C++ objects. Notice that the content which is being edited collaboratively is actually the plain textual format, so a simple algorithm like the one I proposed should be able to handle it with only "insert string" and "delete string" operations. It should be also easy to maintain, since the parts doing the dirty translation job are the import/export to file routines. > But that's the critical point: users won't be able to generate edit msgs > based on the same revision, unless you synch all of them on a master doc. > That may be easy, as discussed with Nico, but it risks of resulting in a > bad experience (wait for a round-trip time before seeing any char on > screen ? hmmm....) > It doesn't require centralization, all users can agree on generating a new revision in a synchronized fashion. Neither it requires blocked wait, the user can keep generating edits to be sent at the next revision step. > I'm absolutely all for users who will synch by themselves / other means, > in such cases. But, should a user try to edit over another user's cursor, > what'd you do ? I'm just saying LyX will automatically remind them that > they shouldn't be messing up with what the other guy is doing, in that > specific region of text. Otherwise they risk their edits to go lost. > Now, don't assume locking is bad. It's not a lock in the traditional > sense, just a highlighting of the risk. > > Now, I can see two variations: I'm not allowed to edit such locked region, > which is what simplifies implementation. Or, when I try to edit, I get a > warning by LyX: look, I'm not sure I can make sense of concurrent edits. > Would you like to proceed ? If the user confirms, then apply some complex > transformational/whatever/git-like algorithm to make sense of the concurrent > edits possibly in a completely ordered and consistent fashion for all editors, > etc..... > The warning could be generated as a courtesy, but in the approach I described, the algorithm would be exactly the same and would be consistent among all editors. >> That's a possibility, but one would have to store a history of >> revisions in case it is needed by someone else. > > Yes, and it should not be a problem to keep in memory a few edits, till > the protocol ensures that all editors have the same vision and allows > for discarding them. > I was thinking about a case in which a user disconnects for some time, it would have to store a lot of earlier revisions. Marcelo
