Hi Mathias,
(Descriptions in the following scenario has been slightly revised)
A division with 100s staffs runs a file server.
1. A general manger sends them an e-mail to see a document in the file server.
2. User A opens the file with OpenOffice.org 3.0 as usual.
3. User B opens the file with OpenOffice.org 3.0 and faces a dialog window
saying
Document file 'xxx.odt' is locked for editing by:
user_a (mm.dd.yyyy hh:mm)
Open document read only or open a copy of the document for editing.
[Open Read Only] [Open Copy] [Cancel]
4. User C opens the file with OpenOffice.org 3.0 and faces the same dialog.
5. User D, one of the line managers, opens it ..., rushes into User A's
booth and scolds that A should not EDIT it.
User A did not intend to edit it or even bother anybody else,
but just wanted to SEE it following the big boss's order.
What we can learn from the scenario above:
(a) The message "Document file 'xxx.odt' is locked for editing by: ..."
might not be appropriate for the situation.
Let's see the following another scenario:
User A |---+------------+-----------------> time line
^open it ^start to make modifications
User B |----------+----------------------->
^open it
User C |-------------------------+-------->
^open it
What message should User B be given? Has User A edited it? Not yet.
What message should User C be given? User A has made modifications.
(b) Timing when a lock file will be created is reconsidered.
So, when the lock file would be created could be one of the points.
There might be no need to create a lock file upon opening a file.
Rather, it would be created as a user starts editing the document.
Mathias Bauer wrote:
> OOo has an option to make a document read-only by default. And users can
> open any document read-only by setting the check mark in the file
> picker. So if user A didn't do that, maybe user D is right with blaming
> him? ;-)
>
> Another (not yet existing option) would be to have an explicit "open
> read-only" menu entry or toolbar button, but that might be an
> exaggeration. Maybe a toolbar button that is invisible by default?
Users normally double-click on an icon of desired file in the Explorer
of Windows, Nautilus of Gnome, ... They might not notice such a wonderful
feature "open in the read-only mode," even though we have implemented it
for desktop of Windows, Gnome, Macintosh, ...
>> "Merge after editing it" model - used by recent version control systems:
CVS, Subversion, git.
>> Current implementation of 3.0 could be considered "Lock before editing it"
model.
>
> The reason why we don't allow for "merge after editing" is that our
> change tracking is not complete in most (all?) applications. Fixing that
> would be a major effort, so it is in concurrency with all other major
> efforts we still have on the list.
Yeah, it would be hard to do that.
Calc 3.0 already has a similar feature called "Share document":
http://www.openoffice.org/dev_docs/features/3.0/#Spreadsheet_Collaboration_Through_Workbook_Sharing
But, how we can natively achieve merging two Impress documents!?
>> Interoperability with other tools
>> Several ODF tools - ODFToolkit, OODoc in Perl, ... - work with ODF files.
>> They, however, do not work with a lock file of 3.x: .~lock.xxx.odt# .
>
> So they can fix that. :-)
>
> We can make this a kind of "public API" of OOo, if that helps. But
> before we do that, there should be some interest from any other ODF
> based application.
I am afraid, but that would make things worse.
Let's see other possible scenarios (some of them could be an external tool):
User A |----+--------------+----------------+--------------> time line
^open it ^modify it ^save it
User X |--------+-------------------------------------+----------->
^open ^close
User Y |-----------+-------------+-------+------------------------>
^open ^modify ^save
User Z |--------------+----------------------------+--------+----->
^open ^modify ^save
There is no need for either User X, Y, or Z to notice who open the file.
There is nothing wrong with User Y.
As both User A and Z attempt to save it, they should be informed that the
file has been altered after they had opened it. They would be prompted to
choose one of the choices:
(a) Overwrite the file with your document
(b) Save your document as another file
(c) Cancel
Therefore, we might not need to utilize a lock file.
All we need might be:
(1) Memorize both a size and digest value such as MD5 check sum of a file
as the file is being opened.
(2) Confirm if the two values have been changed as the file is being saved.
If, at least, one of the values is different from the original value,
prompt the user to ask what to do.
Another cool stuff might be:
As User Z could be informed as Z starts making modifications that the file
has been already altered by someone else (by User A).
Right after User Y has made a modification, User Y could be informed that the
file has been already edited by someone else. To achieve that, a notification
file (its not a LOCK file) could be created upon User A's making a modification.
And User Y's application would recognize it upon starting Y's modifications.
With the idea above -- which is natural behavior of the editor, emacs --,
we could live with not only OOo 3.x itself, but also other external tools,
including OOo 2.x. Some enterprise users are still using OOo 2.x.
Regards,
Tora
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
