Hi Mikhail,
Thank you for the comments.
I am still looking for how to abandon use of file locking since file
locking could not be perfect under current, near future circumstances.
There are already several types of storages in the first decade of the 21th
century.
- local disk device
- local removable device
- Network File System (NFS)
- Common Internet File System (CIFS), aka Samba
- Internet disk
- Explorer-embedded remote disk connectivity
- File Transfer Protocol (FTP) on Windows Explorer
- File access through Web service
- ...
And new types of storage devices and/or systems could follow in the near future.
The idea of file locking with office suites was probably introduced
in 1990s. Computer environment at the time was quite simple.
Users use a Personal Computer which does not connect to other PCs.
The circumstances have changed dramatically in the last two decades and
relevant technology will be uninterruptedly developing, I think.
Mikhail Voytenko wrote:
A criteria of "modified" could be reconsidered.
Yes of course, but the coefficient "efforts/benefits" should be always
in mind while doing so.
I agree.
Somewhat unconvincing scenario:
1. A user downloaded (or checks out) her document file from the
Internet disk yesterday.
2. Today, she starts editing the file with OpenOffice.org.
3. She downloads it again since she forgets when she downloaded
it and ensures she has the latest one.
4. She attempts to save current document on the OpenOffice.org to the
file.
5. She faces ...
On the step 5, what should happen?
A) A dialog window appears with a message:
"The file has been MODIFIED after you had loaded the file"
(in fact, the content of the file has not changed, though)
B) Nothing happens since the content of the file has NOT CHANGED,
even its time stamp has been changed, and she successfully
saves the document to the file.
Actually the step (3) should not be possible. Unfortunately it is
possible because of bugs in system file locking, in those circumstances
(A) looks quite good from my point of view.
Without merging functionality, the action with downloading of the
document to get up-to-date version has no sense anyway. And sorry, but I
see no reason to sacrifice the storing performance to let an absolutely
theoretical from my point of view scenario look a little bit nicer.
Especially if the scenario is only possible because of bug in system
file locking.
1. Start Writer with an empty document.
2. Name it and save it. (A)
Should the file (A) be locked?
3. Save as another file (B)
Should the file (A) be unlocked?
And should the file (B) be locked?
As you might already notice, implementing file lock on just a local
file system is not so simple. How can we perfectly implement it for
several types of, complex, storage devices and/or systems?
Let's go back to the origination.
What is the goal?
What do we need to prevent from?
To satisfy the goal, what options do we have?
File locking is clearly one of the options, but is not the only one.
It might be time to think "Efforts of programmers" vs "Quality of prevention"
Regards,
Tora
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
