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