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

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