Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.