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

[Eike Rathke]

Hi Riccardo,

On Thursday, 2012-03-08 10:39:47 +0000, Michael Meeks wrote:

> > 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.

Right, let's coordinate things a bit. Seems this topic comes up more
frequently recently, we should really avoid conflicting approaches.


> > 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.

That's what I had in mind as well. My approach would be to use
a change-tracking enabled document, because (besides that it gives you
the benefit of being able to display who changed what when) then
actually only trackable (content, not attributes) features are enabled,
and the current file based collaboration (aka shared document) uses this
mode as well, as does the compare/merge document feature. It talso
provides functionality to accept/reject changes. Note that I'm Calc
biased here, Writer doesn't have the shared document feature yet, though
it does have change-tracking.


> > 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 ? :-)

I can commit the remainders of what I have (threw away the first
unpromising approach) to a feature branch this week.


> > 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 ;-).

Actually not that much ;-)

> 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.

This is absolutely a must, especially when it comes to edits that move
things in the document, such as inserting/deleting rows/columns or
moving cells.

> 	* Jabber provides this guarentee :-) and a beautiful way of
> 	  bootstrapping communication from an existing communication
> 	  tool: telepathy/empathy/IM

Yup, and a hard one to deal with..

> 	* Those edits need to do -exactly- the same thing, ie. we'd want
> 	  the same major version of LibreOffice at each end.

I'd rather version the collaboration feature, so each end can
announce/handshake on the minimum collaboration version required,
instead of tie it to the LibO version.

> 	** 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.

That would be a long run, but yes, at the end that's probably what we
want.

> 	* 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.

I don't think tracking cursor locations is needed. An edit action would
be transmitted as "at position (or range) so and so do this and that".

Maybe locking a region to announce "I'm going to edit here" would come
handy to prevent clashes.

In Calc, the ScDocFunc provides almost what's needed and is already used
by UI and API (not consistently, but to a great amount), feeding it from
edit actions as an intermediate layer should be possible. This again
made me think of reusing the existing API and serialize it through
online editing, not sure how far we could go there, but once the basics
were implemented we'd cover a great deal of functionality almost at no
cost.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120312/e59078d6/attachment-0001.pgp>