Q: Is [collaboration] of some interest? [yes!]

[Riccardo Bernardini]

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.meeks at 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.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot
>