Issue 54987

Just to clarify, I was intent on proposing collaborative work for all of
OpenOffice.org, including Writer, Calc, Presenter, etc.  Base could probably
just run through an RDBMS rather than a sexy UI/backend trick.

reassigned to requirements

It would be absolute DYNAMITE to support collaborative editing.

There are two kinds: dynamic (everyone sees the same screen) and Wiki-like
(there's a load and save operation).  For dynamic, don't bother doing it INSIDE
OpenOffice.org; there are tools like X-Windows and kin allowing groups to share
one desktop, and it's probably easier to do it that way.  But for many people
setting up such systems is a pain, and they don't need or want that... they want
a Wiki-like approach, but with all the capabilities of OpenOffice.org.

A Wiki-like approach for OpenOffice.org would be FABULOUS, and it wouldn't even
be hard to implement!  Having this kind of capability might cause non-users of
OpenOffice.org/StarOffice to switch to it.  I'm currently trying to manage
development of a group document. To do it, I'm having to convert the document
FROM OpenOffice TO a Wiki to support group editing, and the Wiki format is not
NEARLY as capable (equations? Styles? nah.).

What I WANT is Wiki-like capabilities where different people can click, edit the
document, and save it back, and have different people's changes automatically
merged.... and for each save, a short summary of what changed. I'd like it to
work on local network files, or across the Internet, and with the option of
various security controls (so it can be protected en route, perhaps only some
can edit, or perhaps only some can read it).  OpenOffice.org actually HAS all
the hard stuff done: in particular, it has track changes and it can merge
changes, as well as a full complement of office capabilities.

Here is a way to implement this in a way that requires very little new code, yet
would add an extraordinary new capability.  More thinking might produce
something even better, but my point is that with a little code you could get a
LOT of really useful functionality.  Basically, every time OOo saves or loads,
it first looks for a special file in the same directory (say the file's base
name plus ".col" for "collaborate") -- we'll call that the "collaborate" file
for the given document.  If collaborate file exists, then you're actually
editing a collaboratively-edited file, and special actions need to be taken. 
Internally, the "collaborate file" will store a sequence number for the
"current" version of the file.  Here is an algorithm I think would work:

On load, if the collaborate file exists, it's locked for reading, and the
sequence number inside read.  A hyphen and this sequence number are inserted
JUST BEFORE the final extension before trying to load the "real" file. Thus, a
File/Load of "/media/share/project/gunk.odt" would first check if
"/media/share/project/gunk.col" exists; and if it exists and said "0020", it
would really load "/media/share/project/gunk-0020.odt".  Store this "previous
sequence number" in the document file.  When loading a file this way (where
there's a collaboration file), automatically turn on "Track Changes" and also
turn on a new parameter "Record Change Reason".

On save, if "Record Change Reason" was turned on, it would first prompt with a
form that asked "Why this change? Summarize:"  and let someone enter the text
in.  This text would be stored somewhere as the latest entry in a "Change
Reason" list inside the document itself along with the author name, date of
save, and the proposed new sequence number.  Now check for the collaboration
file whenever you write it (a user might save in several places, so we have to
be careful here); if it exists, lock the collaboration file for reading/writing
and once that succeeds read it. If the sequence number is unchanged from when
this file was originally loaded, then no one else has changed the document; save
the document with its new full name using the new sequence number current+1
(there shouldn't be such a file currently), save the new sequence number
current+1 in the collaboration file, and unlock the collaboration file.  If the
sequence number HAS changed (to something larger), someone else saved a version
in the meantime while you were editing: unlock the collaboration file, load that
version it referred to, merge your new changes into that, and tell the user
"someone else made changes after you loaded the file; here's the new document
with your changes merged in" or some such (where they conflict, show that too).
Note that in this "conflicts" case, the merged document will have the new
sequence number. The user can edit the file, accept or reject, etc., and then
once they're happy try to save again. Just like Wikipedia or most other Wikis.

A few notes:

* Locking collaborate.id for reading and writing could use lock operations
directly, or could simply use the existance of special files to perform the lock
(the latter probably "works everywhere on everything").

* Note this would mean that working collaboratively on a document works just
like "any other" Wiki.  AND you can use dumb stores to implement this; you don't
need a server at all, though it CAN work with one.

* There is one risk, but it can be countered with a refinement. If a group
collaborates, but then a subgroup creates a separate collaboration location,
works on a document there, and then tries to write their version back, then the
result will be messed up because the sequence numbers won't line up.  A solution
might be to also record in collaborate.id not just the sequence number, but a
cryptographic hash code of the final file (say SHA-256, for the paranoid).  Then
the writer checks to see if their hash code is the same, too; if it is great, if
not, they'll need to search to find the last hash code that they have as a
common ancestor, and use THAT to synchronize.  By adding this refinement,
collaboration should "just work" even if people do crazy things.

* I propose that the set of all historical change reasons be stored in a
document. This isn't strictly necessary (you COULD just store the latest one) if
you don't care about the "subgroup" case, but I think it'd be useful for other
reasons.  Having the history IN the document seems very useful.  And if you
record the hashcode for each version, you'd be able to do the merge described
above EVEN WHEN people do crazy things like break into subgroups (which they
do!). You could store the list of sequence numbers, author names, and "why I
changed" in another "summary file of changes" as well.

* Document the protocol, so that others (like KOffice) can do this, too. Now we
have a REALLY GOOD REASON to for a whole group to use OpenOffice.org (MS Office
has some collaborative capabilities, but I don't think they're free or as easy
as this).  And since this is simply using a shared filestore as a Wiki, it
shouldn't be patented or patentable.

* If people seem to step on each other, they can break the document into pieces
and use a master page.  Making such documents easier to create would be helpful.

* Note that the protocol I've described above gracefully handles the case where
someone loads a file, edits it, writes it several times locally, and eventually
writes it back to the shared location.

* This would work on simple network filesystems as-is, and I'd start there.  But
eventually it'd be nice if it supported other protocols so that sharing could be
safely done across the Internet.  Just support several URLs and protocols, e.g.,
WebDAV (Apache supports that) and sftp (building on ssh).  Encrypt the document
as it goes over the wire, at least optionally.  Make sure they support
(encrypted) passwords, because that's a common way to get things done.

Here are related topics:
* Issue 38770 proposes interacting with a Wiki.  Good idea, and probably still
valuable for working with a group where not everyone wants to use
OpenOffice.org.  But it's not the same thing; such Wikis lose LOTS of
formatting, while here you can just use the tool in its native habitat.
* DokuWiki is an existing macro for handling wikis. Same problem. More infoa at:
http://homepages.paradise.net.nz/hillview/OOo/ and a review at:
http://software.newsforge.com/article.pl?sid=05/01/06/1511255&tid=130&tid=93&tid=13
* Gobby http://gobby.0x539.de/ supports collaborative editing.

I've given all this detail, because I think this would be REALLY USEFUL, and by
creating this level of detail, I hope you can see that it wouldn't be that hard
to do.

Thanks.

Here are more implementation detail ideas, in the hopes that it will help in
implementations.

For a Wiki-like interaction, it might be easiest if the "current" version were
stored with the original name (e.g., "blah.odt" is the CURRENT version;
"blah-0004.odt" is revision 4 of the file).  Or you could store ALL change
information in the file itself, though it'd get bloated in a hurry and I'd worry
about performance.

In any case, some standardized way of automatically supporting Wiki-like
interaction, but with the full capabilities of office suites, would be great.

See http://wiki.koffice.org/index.php?title=Collaboration
for related KOffice discussions.

*** Issue 54987 has been confirmed by votes. ***

"For dynamic, don't bother doing it INSIDE OpenOffice.org; there are tools like
X-Windows and kin allowing groups to share one desktop, and it's probably easier
to do it that way. "

Not really, you would still have to scroll and move the cursor, and now it's
someone else's cursor.

I would love to see Wikipedia's Edit mode turn all AJAX and behave like Gobby,
where everyone sees everyone else's edits in real time and you just wind up
joining the fun.  It's really a better way of collaborating, it's like working
on a physical thing together (complete with a chat box in Gobby...).

A Wiki-like editing mode would be a mistake.  Suddenly there's a pop-up, "This
document has changed, attempting to diff together the changes.  Does this look
right?  Some of your edits are now in a section that moved... I think... it's
also different, I can't find it."

http://www.ntu.edu.sg/home/czsun/ has done some possibly relevant work (see CoWriter/CoCalc/CoImpress on that page) but hard to tell whether there's any code.

*** Issue 91444 has been marked as a duplicate of this issue. ***

*** Issue 84271 has been marked as a duplicate of this issue. ***