Hi Michael, quite a reply you wrote! To be honest, I am quite in a rush right now, so I just skimmed it, but I plan to read it with more leisure later tomorrow. I like to see that this idea has been positively received. I'll come back in the next few days.
Riccardo On Thu, Mar 8, 2012 at 11:39 AM, Michael Meeks <michael.me...@suse.com> wrote: > Hi Riccardo, > > On Wed, 2012-03-07 at 15:39 +0100, Riccardo Bernardini wrote: >> I believe this is the right list for this message. If it is not, >> please point me to the right list (and accept my apologizes). > > No - this is a great place to do this. > >> For several reasons (let me skip them), at my University we are >> thinking about starting a project involving ODF and we would like to >> know if there is already something similar to what we would like to >> produce and it the LibreOffice community could have some interest in >> it. > > Wonderful - there is already some similar work underway that Eike is > looking into, it would be great to have you work with him. > >> The project is about providing LibreOffice with a "Google Docs-like" >> simultaneous editing capability, but with some improvements and a >> bazaar (or git) flavor. > > Ok - so, in the model I'm recommending, the git flavour would be > something orthogonal. > >> In our vision, each user has control about a "section" of the text >> (for simplicity, we are aiming mainly to text documents) and every >> changes made to the document are propagated to all the users currently >> on-line (with an experience similar to "Google Docs"). > > Right, > >> The difference with Google Docs is that the document is not in some >> fuzzy "cloud," but on the user's disk and the user can edit it while >> off-line, encrypt it, ... If the user does some changes while off-line, >> the other copies will receive the updates as soon as the user returns >> on-line. Different copies will exchange updates in a peer-to-peer >> fashion, without the need of a centralized repository (the bazaar/git >> flavor). > > Ok - so, (I hope) our focus first would be the on-line co-editing, and > then use/fall-back to (and improve) the document merging / comparison > functionality to do on-line/off-line merges. > >> This feature is my "personal itch" since I would actually use to write >> "many-hands" documents together with colleagues. Moreover, it would be >> an important feature of LibreOffice, not shared by other editing >> solutions. > > Sure. > >> We are aware that there are many technical issues. For some issues we >> have solutions, for others we are still "combing our ideas." However, >> before going beyond the "idea combing" stage, I would like to ask the >> following questions: > > :-) > >> 1. Are you aware if this type of capability is already available (I >> do not think so) or currently developed? > > There is work underway, to bootstrap this via instant messaging, and > particularly the Telepathy framework - it would be great to make that > more public / visible and get more hands onto playing with it. Eike - do > you have something that could go into a feature branch ? :-) > >> 2. Has the LibreOffice community some interest in this idea? If it >> has, this would give us a stronger motivation. > > Yes - of course, we're here to help guide you towards a design that is > complementary to what we're doing, fits well with the code-base, and > other people etc. :-) And to some degree I'm here to try to support > others to help them do cool things with the code-base, of which this is > clearly one. > >> 3. Do you have some general suggestions for us? Especially about >> interfacing the rest of the developers. > > So - first, talk to Eike (preferably CC'ing the list here). Second - > here is what I was trying to persuade Eike was a sensible way of doing > it (which he's prolly detected as insane already ;-). Please bear in > mind we're starting with calc here ... > > Here are my thoughts: > > * It doesn't matter what you do to the document, as long as > everyone's document does the same thing. > > * Thus - whatever protocol you use, it needs to enforce hard > ordering, such that edits 'A1', 'B1', 'A2' 'C1' end up in > the same order for A, B, and C regardless of latency / > topology etc. > > * Jabber provides this guarentee :-) and a beautiful way of > bootstrapping communication from an existing communication > tool: telepathy/empathy/IM > > * Those edits need to do -exactly- the same thing, ie. we'd want > the same major version of LibreOffice at each end. > > ** But ** - and here is where the work starts > > * We need to ensure that all edits to the document are not > applied immediately, but described and dispatched to the > Jabber server, and only the events returned are applied. > > * This means we need a -clean- Controller <-> Model split > which we currently don't have ;-) -although- some things > are really quite pleasant, eg. dialogs often tend not to be > instant apply, and to collect up their changes into > abstract SfxItemSets (PropertyBags to you and me) so with > work we can tease out the controller perhaps. > > * And of course, some thinking of good ways of managing > cursor locations, and transmitting other people's > movement around documents to maintain sensible editing state > is necessary. > > This is not a perfect model of course, but it is conceptually very > simple & I hope robust. It may mis-behave, but it should -always- > mis-behave identically everywhere :-) > > Here are some anti-thoughts, ie. steer clear below :-) > > * Hooking Undo / Redo is not a better model > + other approaches tend to serialize undo information, > this provides a similar approach, it relies on > mostly matching semantics > + yet really you need to serialize the undo information > from just before your edit was applied, since > otherwise state can get out of sync, yet you can't > know what that is until all edit events have come in > to your latest one. > + also you only want to send 1/2 the undo information - > consider deleting a row or column in calc - this can > generate a staggering volume of undo data. > + ergo - I think that building and testing a clean MV-C > split is a better way-point, and layering some clever > undo/re-do presentation on top of that would be > better. > > * inspect & synchronise is not either > + most lame collaboration solutions do instant local > apply (ie. at least you see your edit fast) > + then they try (often via UNO - ie. with one hand > chopped off ;-) to detect those changes to the > document > + then they try to serialise that, and send it remotely > + as you can imagine running into conflicting edits here > is a disaster of trying to unwind and re-apply code > changes. > > Anyhow - as you can see, I'm personally rather interested in this > topic, and would love to watch / help out from time to time with it. It > is one of the last big missing pieces in our development picture - it > would be awesome to have more people working on it. I really do think > that Calc is the best place to prototype this too. > > Will you be working this summer ? and/or would you like to be involved > in a Google Summer of Code project on this topic ? > > All the best, > > Michael. > > -- > michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice