Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||FRQ: Collaborative editing|
|Component:||ui||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P5 (lowest)||CC:||alexandre0984, bryce.schober, issues, ml, petertrypsteen|
|Version:||OOo 3.0 Beta|
|Issue Type:||FEATURE||Latest Confirmation in:||---|
Description nigelenki 2005-09-22 22:02:19 UTC
After taking a peek at Gobby (http://gobby.0x539.de/), I realized that collaborative work is actually a fairly awesome idea. A possible future feature of OpenOffice.org could be collaborative work; this would definitely set OOo apart from any existing office suite. An important considerations for this would include encryption, since sometimes documents contain confidential information. Most stream ciphers like RC4 are either underused and thus haven't withstood the test of time, or horribly insecure. Block ciphers on the other hand operate on fixed-size blocks and have waste when used for real-time applications, as they need padding. AES is accepted to be secure, and uses a 128-bit (16 byte) block cipher. It might be possible to use something like a variation on Resudiual Block Termination for series of data that are bigger than a block but not exactly the size of N blocks; although padding will probably be easier. Anyone else have input on the idea?
Comment 1 nigelenki 2005-09-22 22:03:59 UTC
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.
Comment 2 mci 2005-09-28 19:23:44 UTC
reassigned to requirements
Comment 3 dwheeler 2005-10-21 18:25:30 UTC
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.
Comment 4 dwheeler 2005-10-24 22:27:23 UTC
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.
Comment 5 dwheeler 2007-04-09 05:28:28 UTC
See http://wiki.koffice.org/index.php?title=Collaboration for related KOffice discussions.
Comment 7 nigelenki 2008-06-05 01:04:52 UTC
"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."
Comment 8 mlinksva 2011-04-16 19:27:07 UTC
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.
Comment 9 Edwin Sharp 2014-01-19 19:18:26 UTC
*** Issue 91444 has been marked as a duplicate of this issue. ***