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

[Michael Meeks]

Hi Riccardo,

On Sat, 2012-03-24 at 17:59 +0100, Riccardo Bernardini wrote:
> sorry for the long silence.  I wanted to write a thoughtful reply and
> finally I got a timeslot long enough (I am doing an 8-hours train
> trip.  That should be plenty).

	Nice ! :-) so - in the meantime there is a feature/tubes2 branch that
you can play with if you want to see a nice live demo.

> A first difference between my model and yours is that yours has a
> "Google doc" flavor where everyone can edit everything  (although Eike
> suggests a region locking), while in my model different document
> regions are assigned to different editors and each editor can modify
> only his own region.

	OK ? the Microsoft model is to 'lock cell', 'lock paragraph', 'lock
slide' - and that seems to work reasonably well / simply.

> This would also solve the problem of serializing the changes.

	Sure, it's a simpler problem domain.

> Maybe another important difference is that you are thinking about
> showing  "in real time" to each editor the changes made by the other
> editors.  Instead I am thinking about transferring the changes in a
> "batch" mode, not sending the "editing commands," but updates in the
> actual structure of the document. A rough description of what would
> happen is the following:

	Sounds fine; so this could be done with the existing merge-document /
change-tracking code I guess; at least if conflicts are guarenteed not
to happen.

> smaller version number, they will execute (b) sending their own
> version numbers.   When the replies of the other nodes will be
> received by Alice, she will be in case (c) and will begin sending
> updates to the group.

	IMHO getting shared versioning right is a tough problem - the best
practise here IMHO would be to use a hash of the document and to
remember which states we've been through in the past to work out who
should merge what.

>       ----------
>      /          \
>      | Document |
>      \__________/
>           ^
>           |
>           v
>      +------------+    User
>      | Editing    |  commands  +---------+
>      | "engine"   |<-----------|   GUI   |
>      +------------+            +---------+

	So the problem with all of this, of course is to cleanly split the
model and the view. We're looking at this work in calc, and it's a big
job.

	More than splitting model & view, we need to cut the operations on the
model down hugely - from things like:

	"insertAutoDetectFormatCombineWithAutoFillAcrossSheetSelections"

	(a made-up name to try to represent a complex method with lots of side
effects), into groups of much simpler operations that achieve the same
thing.

> OK, I hope you are still with me and you did not fall (asleep) from
> your chair... ;-)

	So - I skimmed it all :-)

> This is the model that I had in mind, model that I thought without
> knowing anything about LO structure and just a very tiny bit about ODF
> format, so maybe there are some deep incompatibilities.   I like it
> because of its simple structure and the "symmetry" between the nodes
> (the "git" flavor), but, of course, there is nothing sacred about it.

	I'm sure your design works nicely in an abstract sense, and could be
developed more to make it more compelling etc. Clearly revision control
systems deal with lots of these problems, and there are infinite
directions we could take the code-base in.

	Here is my concern though: that creating a nice design is almost never
the problem with LibreOffice features - the -real- heavy-duty
engineering work comes from working out the least-bad design, that
allows migration to something better in future, that can actually be
achieved in linear time and at the same time improves the existing
code-base :-)

	Personally, I think our suggested design can move us in a positive
direction in terms of code structure: moving towards a clearer
model/view/controller separation, and achieve something that is useful
along the way. It is also not a massive "do or die" project :-) [ these
rather tend to die incidentally ;-].

	So - anyhow, please do have a look at the feature/tubes2 branch and see
if you can get it to work (you'll need a recent Linux though).

	All the best,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot