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
Attachment:
pgp0vs970neQN.pgp
Description: PGP signature