Re: [dev] Document file lock system could be enhanced
Hi Eike, The idea sounds good. The problem is that we can not currently 100%-correct say whether current user is able to open the document ( ACL and so on in heterogeneous network can make life complex ), we have to try to open it to know it for sure. In those circumstances it would be problematic to detect whether other users would be able to edit the document. Another possible minus, it could be confusing for some users, who do not know much about access rights. Best regards, Mikhail. On 06/23/09 12:51, Eike Rathke wrote: Hi Mikhail, On Monday, 2009-06-22 07:26:03 +0200, Mikhail Voytenko wrote: In other words, there should be a possibility to configure office in the way, that it opens the documents readonly always. If user wants to edit the opened document, he has to switch the document to edit mode explicitly. Just a quick idea: let the preferred open mode also depend on the file's access permission properties. If a file's permissions allow only the current user write access there's no reason to open it read-only. Eike
Re: [dev] Document file lock system could be enhanced
Hi Mikhail, On Monday, 2009-06-22 07:26:03 +0200, Mikhail Voytenko wrote: > In other words, there should be a possibility to configure office in the > way, that it opens the documents readonly always. If user wants to edit > the opened document, he has to switch the document to edit mode > explicitly. Just a quick idea: let the preferred open mode also depend on the file's access permission properties. If a file's permissions allow only the current user write access there's no reason to open it read-only. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the e...@sun.com account, which I use for mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks. pgpRj8IYrP5Mq.pgp Description: PGP signature
Re: [dev] Document file lock system could be enhanced
tora - Takamichi Akiyama wrote: > Hi Mikhail, > > Mikhail Voytenko wrote: >> although the provided document handling scenario looks to be a little >> bit strange for me, opening the document readonly as Mathias has already >> suggested would be the solution. In your case the documents are opened >> from the file explorer. So you need probably a possibility to let office >> open every file readonly by default. > > Could you provide us with a user scenario using a possible solution "opening > all documents readonly by default"? > > case A) a single user handling an existing document file; when the file gets > locked and when unlocked? > case B) two users sharing one document file in a file server and one user > editing it > case C) multiple users sharing one document file in a file server and some > users unexpectedly editing it simultaneously > case D) File - Save As, previous one unlocked and new one locked, become > readonly? > case E) Starting with an empty file (couldn't be readonly) and File - Save, > become readonly, locked? Mikhail didn't suggest this as a solution for all problems, but for some of them. I understand, you are asking for a "do not lock and merge changes" solution. This would be nice to have, but we don't have a merging procedure that works 100% correct in 100% of all possible cases. As we value prevention of data loss or data corruption higher than convenience (or, if you want: prevention of annoyance), we can't work without locking. The first step away from file locking would be to have a perfect merging algorithm for all document types. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, The current design is quite easy, if a document is opened read-only it is not locked. If document is opened for editing it is locked. I must confess, I do not quite understand which scenario do you expect from me. Actually we have discussed scenario you have provided, and I have only suggested a possible solution for it. It would help in the scenario you have described, since to edit document the user would have to explicitly switch to edit mode using "Edit" button: Another scenario, "Locked out by a reviewer" 1. User A has created an Impress document for a meeting held this afternoon. 2. User A sends an e-mail to her college User B to ask reviewing it. 3. User B opens the document file stored in their file server. 4. Lunch time has come and User B goes to the restaurant. 5. User A has found some errors in the document. 6. User A tries to load the document, but gets warned "The file is locked by the User B." Best regards, Mikhail. On 06/22/09 08:09, tora - Takamichi Akiyama wrote: Hi Mikhail, Mikhail Voytenko wrote: although the provided document handling scenario looks to be a little bit strange for me, opening the document readonly as Mathias has already suggested would be the solution. In your case the documents are opened from the file explorer. So you need probably a possibility to let office open every file readonly by default. Could you provide us with a user scenario using a possible solution "opening all documents readonly by default"? case A) a single user handling an existing document file; when the file gets locked and when unlocked? case B) two users sharing one document file in a file server and one user editing it case C) multiple users sharing one document file in a file server and some users unexpectedly editing it simultaneously case D) File - Save As, previous one unlocked and new one locked, become readonly? case E) Starting with an empty file (couldn't be readonly) and File - Save, become readonly, locked? ... I have been trying to imagine that, and found it is hard for me. In other words, there should be a possibility to configure office in the way, that it opens the documents readonly always. If user wants to edit the opened document, he has to switch the document to edit mode explicitly. The feature would be a consistent part of the current design, so please submit a new feature request to me ( m...@openoffice.org ) for this. PS: Please try to avoid writing words with capital letters without necessity, ... Thank you for the suggestion. I will keep it in mind. Best Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Mikhail, P.S. I do not think we are in hurry. It is Monday today. Please keep your time for more important things. I would be also trying to devise some user scenarios with all-the-time-starting-with-read-only documents. Regards, Tora tora - Takamichi Akiyama wrote: Hi Mikhail, Mikhail Voytenko wrote: although the provided document handling scenario looks to be a little bit strange for me, opening the document readonly as Mathias has already suggested would be the solution. In your case the documents are opened from the file explorer. So you need probably a possibility to let office open every file readonly by default. Could you provide us with a user scenario using a possible solution "opening all documents readonly by default"? case A) a single user handling an existing document file; when the file gets locked and when unlocked? case B) two users sharing one document file in a file server and one user editing it case C) multiple users sharing one document file in a file server and some users unexpectedly editing it simultaneously case D) File - Save As, previous one unlocked and new one locked, become readonly? case E) Starting with an empty file (couldn't be readonly) and File - Save, become readonly, locked? ... I have been trying to imagine that, and found it is hard for me. In other words, there should be a possibility to configure office in the way, that it opens the documents readonly always. If user wants to edit the opened document, he has to switch the document to edit mode explicitly. The feature would be a consistent part of the current design, so please submit a new feature request to me ( m...@openoffice.org ) for this. PS: Please try to avoid writing words with capital letters without necessity, ... Thank you for the suggestion. I will keep it in mind. Best Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Mikhail, Mikhail Voytenko wrote: although the provided document handling scenario looks to be a little bit strange for me, opening the document readonly as Mathias has already suggested would be the solution. In your case the documents are opened from the file explorer. So you need probably a possibility to let office open every file readonly by default. Could you provide us with a user scenario using a possible solution "opening all documents readonly by default"? case A) a single user handling an existing document file; when the file gets locked and when unlocked? case B) two users sharing one document file in a file server and one user editing it case C) multiple users sharing one document file in a file server and some users unexpectedly editing it simultaneously case D) File - Save As, previous one unlocked and new one locked, become readonly? case E) Starting with an empty file (couldn't be readonly) and File - Save, become readonly, locked? ... I have been trying to imagine that, and found it is hard for me. In other words, there should be a possibility to configure office in the way, that it opens the documents readonly always. If user wants to edit the opened document, he has to switch the document to edit mode explicitly. The feature would be a consistent part of the current design, so please submit a new feature request to me ( m...@openoffice.org ) for this. PS: Please try to avoid writing words with capital letters without necessity, ... Thank you for the suggestion. I will keep it in mind. Best Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, although the provided document handling scenario looks to be a little bit strange for me, opening the document readonly as Mathias has already suggested would be the solution. In your case the documents are opened from the file explorer. So you need probably a possibility to let office open every file readonly by default. In other words, there should be a possibility to configure office in the way, that it opens the documents readonly always. If user wants to edit the opened document, he has to switch the document to edit mode explicitly. The feature would be a consistent part of the current design, so please submit a new feature request to me ( m...@openoffice.org ) for this. Best regards, Mikhail. PS: Please try to avoid writing words with capital letters without necessity, this let the sentence look like a cry, such emails usually get less attention on the list. I have now answered because we continue the already started discussion. On 06/19/09 14:01, tora - Takamichi Akiyama wrote: Hi, Please DO NOT LOCK a file when a user just loads a file. Mikhail, I do not want to bother you, but, ... Please, please, make "productive office suite" more PRODUCTIVE. Another scenario, "Locked out by a reviewer" 1. User A has created an Impress document for a meeting held this afternoon. 2. User A sends an e-mail to her college User B to ask reviewing it. 3. User B opens the document file stored in their file server. 4. Lunch time has come and User B goes to the restaurant. 5. User A has found some errors in the document. 6. User A tries to load the document, but gets warned "The file is locked by the User B." 7. User A calls the User B, but hears a message from B's answering machine. 8. The meeting is arranged at 1:00pm. It is 12:30 now. 9. User A tries to call User C to ask to close User B's document. 10. User C, however, is also at the restaurant with B. 11. User A runs to User B's booth located in another building. 12. I know, they are not so stupid. But this type of scenario could be seen here and there since office suite software products are widely used by from children to elderly people. The similar situation could be also observed in an elementary school, etc. Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi, Please DO NOT LOCK a file when a user just loads a file. Mikhail, I do not want to bother you, but, ... Please, please, make "productive office suite" more PRODUCTIVE. Another scenario, "Locked out by a reviewer" 1. User A has created an Impress document for a meeting held this afternoon. 2. User A sends an e-mail to her college User B to ask reviewing it. 3. User B opens the document file stored in their file server. 4. Lunch time has come and User B goes to the restaurant. 5. User A has found some errors in the document. 6. User A tries to load the document, but gets warned "The file is locked by the User B." 7. User A calls the User B, but hears a message from B's answering machine. 8. The meeting is arranged at 1:00pm. It is 12:30 now. 9. User A tries to call User C to ask to close User B's document. 10. User C, however, is also at the restaurant with B. 11. User A runs to User B's booth located in another building. 12. I know, they are not so stupid. But this type of scenario could be seen here and there since office suite software products are widely used by from children to elderly people. The similar situation could be also observed in an elementary school, etc. Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
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
Re: [dev] Document file lock system could be enhanced
Hi Tora, On 06/19/09 09:25, tora - Takamichi Akiyama wrote: Hi Mikhail, Mikhail Voytenko wrote: > I think I see the problem. Probably you have exactly the case when file > system locking does not work. And the current implementation checks > whether the file was changed only if system file locking is not used by > the document. That is of course a bug, actually the OOo locking > mechanics was introduced to workaround the known problems with the > system file locking, so the check should be active always. I have just > submitted a new issue to myself > http://qa.openoffice.org/issues/show_bug.cgi?id=102701 You mean this? http://www.openoffice.org/issues/show_bug.cgi?id=102931 Yes, sorry for the copy-paste error. By the way, there would be some ways to confirm if a target file has been modified. (a) time stamp of a target file (b) digest value of a target file (c) original content of a target file The current OOo implementation uses (a). The (b) could be discussed if there is necessity for check improvement, but it would still affect the performance. The (c) is no option from my point of view. As you know, Subversion is not using (a) to find modified files. Subversion has completely different task, and has to handle much more complex scenarios. So it's behavior can not be treated as argument here from my point of view. A criteria of "modified" could be reconsidered. Yes of course, but the coefficient "efforts/benefits" should be always in mind while doing so. As time goes, there would be more and more heterogeneous computing environments surrounding users. 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. I am not sure that which is better for current the generation of users: (A) comparing a time stamp of the file to determine modifications (B) comparing contents of the file to determine modifications But I bet (B) would be better for the future. Please see above. (B) seems to make sense only for the case of shared documents if there is merging functionality. Best regards, Mikhail. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Mikhail Voytenko wrote: > By the way, "SAL_ENABLE_FILE_LOCKING" does only affect sal > implementation. So if it is not set the framework and office > implementation still believes that the system file locking is used, at > least the implementation requests sal to use it ( actually this variable > looks to be a hack for me ). To let the framework not use the system > file locking, there is a configuration entry > "/org.openoffice.office.Common/Misc/UseDocumentSystemFileLocking", that > let framework request no system file locking from sal for documents. I think we should remove the support for "SAL_ENABLE_FILE_LOCKING". It's confusing and prone to errors. Alternatively, OOo must automatically synchronize that variable and the configuration setting. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Mikhail, Mikhail Voytenko wrote: > I think I see the problem. Probably you have exactly the case when file > system locking does not work. And the current implementation checks > whether the file was changed only if system file locking is not used by > the document. That is of course a bug, actually the OOo locking > mechanics was introduced to workaround the known problems with the > system file locking, so the check should be active always. I have just > submitted a new issue to myself > http://qa.openoffice.org/issues/show_bug.cgi?id=102701 You mean this? http://www.openoffice.org/issues/show_bug.cgi?id=102931 By the way, there would be some ways to confirm if a target file has been modified. (a) time stamp of a target file (b) digest value of a target file (c) original content of a target file As you know, Subversion is not using (a) to find modified files. 1. A programmer checks out source files from a repository. 2. He edits one of the source files and save it. 3. "svn status" reports "M filename" meaning "the file is locally modified." 4. He edits it again and "undo" the modifications and save it. 5. "svn status" reports nothing meaning "no file locally has been modified." Through the steps above, a time stamp of the file has been definitely changed. But, its content at the step 5 is the same as the original at the step 1. A criteria of "modified" could be reconsidered. As time goes, there would be more and more heterogeneous computing environments surrounding users. 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. I am not sure that which is better for current the generation of users: (A) comparing a time stamp of the file to determine modifications (B) comparing contents of the file to determine modifications But I bet (B) would be better for the future. By the way, "SAL_ENABLE_FILE_LOCKING" does only affect sal implementation. So if it is not set the framework and office implementation still believes that the system file locking is used, at least the implementation requests sal to use it ( actually this variable looks to be a hack for me ). To let the framework not use the system file locking, there is a configuration entry "/org.openoffice.office.Common/Misc/UseDocumentSystemFileLocking", that let framework request no system file locking from sal for documents. I would give it a try on a local file system using physical disk devices. Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, I think I see the problem. Probably you have exactly the case when file system locking does not work. And the current implementation checks whether the file was changed only if system file locking is not used by the document. That is of course a bug, actually the OOo locking mechanics was introduced to workaround the known problems with the system file locking, so the check should be active always. I have just submitted a new issue to myself http://qa.openoffice.org/issues/show_bug.cgi?id=102701 Thank you for finding the problem. By the way, "SAL_ENABLE_FILE_LOCKING" does only affect sal implementation. So if it is not set the framework and office implementation still believes that the system file locking is used, at least the implementation requests sal to use it ( actually this variable looks to be a hack for me ). To let the framework not use the system file locking, there is a configuration entry "/org.openoffice.office.Common/Misc/UseDocumentSystemFileLocking", that let framework request no system file locking from sal for documents. Best regards, Mikhail. On 06/18/09 11:55, tora - Takamichi Akiyama wrote: The step 4 can not overwrite the file because the system file locking is active. If it was turned off, it would overwrite the document and the step 6 should show the warning. I am not sure about the reasons. The file (a) is /home/tora/z.odt . The directory /home/tora is NFS auto-mounted. I can do the step 4 without error. I have confirmed again and again. It seems that the file is not locked by the OS or NFS. I have not touched the Shell script /opt/openoffice.org3/program/soffice . It has the lines below: === # file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING === Anyway, I would be browsing the CWSs. Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Mikhail, Thank you for the cue. Mikhail Voytenko wrote: There was a feature mail notification regarding this. Please take a look to the changes introduced for cws mav43. There are a number of issues related to the file locking. 1. Prepare two existing .odt files: (a) and (b). 2. Start OpenOffice.org DEV300_m48. 3. Open (a) with the OOo. 4. Overwrite (a) with (b) using 'cp' UNIX command. 5. Make modifications on OOo. 6. Save the document by pressing Ctrl-S. The step 4 can not overwrite the file because the system file locking is active. If it was turned off, it would overwrite the document and the step 6 should show the warning. I am not sure about the reasons. The file (a) is /home/tora/z.odt . The directory /home/tora is NFS auto-mounted. I can do the step 4 without error. I have confirmed again and again. It seems that the file is not locked by the OS or NFS. I have not touched the Shell script /opt/openoffice.org3/program/soffice . It has the lines below: === # file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING === Anyway, I would be browsing the CWSs. Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, On 06/18/09 11:27, tora - Takamichi Akiyama wrote: Hi Mikhail, Mikhail Voytenko wrote: OOo3.1 has already collision detection system, although it is mostly useful in case system file locking is turned off. If the document was changed during the editing the user gets notification that he might remove changes from somebody else. If the system file locking is on, the mentioned scenario is only possible when the system file locking does not work as expected. That might happen in heterogeneous networks. Is there any document, reference, issue, ... on that? There was a feature mail notification regarding this. Please take a look to the changes introduced for cws mav43. There are a number of issues related to the file locking. With DEV300_m48 locally built on OpenSolaris x86, I cannot know how to enjoy with it. 1. Prepare two existing .odt files: (a) and (b). 2. Start OpenOffice.org DEV300_m48. 3. Open (a) with the OOo. 4. Overwrite (a) with (b) using 'cp' UNIX command. 5. Make modifications on OOo. 6. Save the document by pressing Ctrl-S. Nothing seems to happen. Maybe, I am doing somewhat wrongly. The step 4 can not overwrite the file because the system file locking is active. If it was turned off, it would overwrite the document and the step 6 should show the warning. Best regards, Mikhail. Regards, Tora On 06/17/09 06:42, tora - Takamichi Akiyama wrote: 2. Collision detection User A |++-+--> time line ^open^modify ^save 12 3 User X |+++-> ^open^modify ^save 456 User X could be informed that the disk file has been altered by someone else -(6) and prompted: (a) Overwrite the file with yours (Warning: someone else's changes will be lost) (b) Save your document as another file (c) Cancel - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Mikhail, Mikhail Voytenko wrote: OOo3.1 has already collision detection system, although it is mostly useful in case system file locking is turned off. If the document was changed during the editing the user gets notification that he might remove changes from somebody else. If the system file locking is on, the mentioned scenario is only possible when the system file locking does not work as expected. That might happen in heterogeneous networks. Is there any document, reference, issue, ... on that? With DEV300_m48 locally built on OpenSolaris x86, I cannot know how to enjoy with it. 1. Prepare two existing .odt files: (a) and (b). 2. Start OpenOffice.org DEV300_m48. 3. Open (a) with the OOo. 4. Overwrite (a) with (b) using 'cp' UNIX command. 5. Make modifications on OOo. 6. Save the document by pressing Ctrl-S. Nothing seems to happen. Maybe, I am doing somewhat wrongly. Regards, Tora On 06/17/09 06:42, tora - Takamichi Akiyama wrote: 2. Collision detection User A |++-+--> time line ^open^modify ^save 12 3 User X |+++-> ^open^modify ^save 456 User X could be informed that the disk file has been altered by someone else -(6) and prompted: (a) Overwrite the file with yours (Warning: someone else's changes will be lost) (b) Save your document as another file (c) Cancel - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, OOo3.1 has already collision detection system, although it is mostly useful in case system file locking is turned off. If the document was changed during the editing the user gets notification that he might remove changes from somebody else. If the system file locking is on, the mentioned scenario is only possible when the system file locking does not work as expected. That might happen in heterogeneous networks. Best regards, Mikhail. On 06/17/09 06:42, tora - Takamichi Akiyama wrote: Hi, Why don't we, at least, consider letting OpenOffice.org have a collision (or conflict) detection system to prevent loosing someone else's efforts. tora - Takamichi Akiyama wrote: 2. Collision detection User A |++-+--> time line ^open^modify ^save 12 3 User X |+++-> ^open^modify ^save 456 User X could be informed that the disk file has been altered by someone else -(6) and prompted: (a) Overwrite the file with yours (Warning: someone else's changes will be lost) (b) Save your document as another file (c) Cancel Related scenarios: http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=24974 Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi, Why don't we, at least, consider letting OpenOffice.org have a collision (or conflict) detection system to prevent loosing someone else's efforts. tora - Takamichi Akiyama wrote: 2. Collision detection User A |++-+--> time line ^open^modify ^save 12 3 User X |+++-> ^open^modify ^save 456 User X could be informed that the disk file has been altered by someone else -(6) and prompted: (a) Overwrite the file with yours (Warning: someone else's changes will be lost) (b) Save your document as another file (c) Cancel Related scenarios: http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=24974 Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi, (Refined) Goals - More productively collaborative work Stages: 5. Work flow or things like that 4. Merge after edit 3. Collision precaution 2. Collision detection 1. Lock before edit (current) 5. Work flow or things like that (I have no idea about this topic.) 4. Merge after edit Both Writer and Calc could utilize the already-implemented feature, "Edit - Compare Document..." to find differences between user's current document and a document file that someone else have saved. Two documents would be displayed side by side: CurrentDisk file +-++-+ | xxx || xxx | | || | # aaa ## mmm # <-- differences would be marked # b ## nnn # in different color and shape | xxx || xxx | | yy || yy | Each chunk has choices: +-++-+[Yours] [Other's] [Back] [Skip] [Cancel] Impress might implement "Edit - Compare Document..." which would find differences slide by slide. Scenario A team of several people has been creating an Impress document with 100s slides. User A is responsible for the section 1 ranging slide 1 to 20. User B is working on the section 2 ranging slide 21 to 39. User C is ... To help their collaborative work, Impress could implement "Share document" or "Merge after edit." Actually, they might be quite similar each other. E.g. Calc 3.0's "Share document" could be considered "Merge after edit." http://www.openoffice.org/dev_docs/features/3.0/#Spreadsheet_Collaboration_Through_Workbook_Sharing User interface for the situation -(6) below would be: (a) Overwrite the file with yours (Warning: someone else's changes will be lost) (b) Save your document as another file (c) Compare and/or Merge (will show differences between (3) and (6), and help User X merge them) (d) Cancel 3. Collision precaution User A |++-+--> time line ^open^modify ^save 12 3 User X |+++-> ^open^modify ^save 456 User Y |---+---+---+> ^open ^modify ^save 7 8 9 User X could be informed that the disk file has been altered by someone else -(5) and prompted: (a) Proceed (Warning: collision would happen upon save) (b) Retrieve the latest file from disk (same as File - Reload) (c) Cancel User Y could be informed that someone else has started to edit the document -(8) and prompted: (a) OK (Warning: collision would happen upon save) (b) Cancel To implement that, (a) Create a notification file -(2). (b) Check the existence of notification file -(5), (8). 2. Collision detection User A |++-+--> time line ^open^modify ^save 12 3 User X |+++-> ^open^modify ^save 456 User X could be informed the the disk file has been altered by someone else -(6) and prompted: (a) Overwrite the file with yours (Warning: someone else's changes will be lost) (b) Save your document as another file (c) Cancel To implement that, (a) Memorize both a size and digest value such as MD5 check sum of a file -(4). (b) Retrieve the values of the disk file again, and verify them -(6). If, at least, one of them is different from the original value, prompt the user to ask what to do. 1. Lock before edit (current) 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. 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 ..., and rushes into User A's booth and scolds A not to EDIT it. User A did not intend to edit it or even bother anybody else, but just wanted to SEE it. User A |---++-> time line ^open it ^start editing it 12 User B |--+---> ^open 3 User C |-+> ^open
Re: [dev] Document file lock system could be enhanced
> What we can learn from the scenario above: That the company in question doesn't have a proper document management process (workflow)? --tml - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
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. 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
Re: [dev] Document file lock system could be enhanced
Yep, I mean ACL scenarios. i96918 is targeted for 3.2, so my question is answered. Thanks a lot! WBR, KP. Mikhail Voytenko ?: Hi, If the ACL problem is meant, please take a look to the issue http://qa.openoffice.org/issues/show_bug.cgi?id=96918 Actually this issue should affect not only ACL scenarios, but also other rare scenarios when the file permissions detection of OOo is confused. Best regards, Mikhail. On 06/04/09 19:33, Mathias Bauer wrote: Kirill Palagin wrote: Mathias, let me jump in - is there a solution planned (or even possible) for case where user opens file with full access rights from location with read-only rights? Currently we open the file in read-only mode, while everybody else allows the file to be edited and saved. Are you talking about paying attention to ACL? Or what do you have in mind? Regards, Mathias - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi, If the ACL problem is meant, please take a look to the issue http://qa.openoffice.org/issues/show_bug.cgi?id=96918 Actually this issue should affect not only ACL scenarios, but also other rare scenarios when the file permissions detection of OOo is confused. Best regards, Mikhail. On 06/04/09 19:33, Mathias Bauer wrote: Kirill Palagin wrote: Mathias, let me jump in - is there a solution planned (or even possible) for case where user opens file with full access rights from location with read-only rights? Currently we open the file in read-only mode, while everybody else allows the file to be edited and saved. Are you talking about paying attention to ACL? Or what do you have in mind? Regards, Mathias
Re: [dev] Document file lock system could be enhanced
Kirill Palagin wrote: > Mathias, > let me jump in - is there a solution planned (or even possible) for case > where user opens file with full access rights from location with > read-only rights? Currently we open the file in read-only mode, while > everybody else allows the file to be edited and saved. Are you talking about paying attention to ACL? Or what do you have in mind? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Mathias, let me jump in - is there a solution planned (or even possible) for case where user opens file with full access rights from location with read-only rights? Currently we open the file in read-only mode, while everybody else allows the file to be edited and saved. WBR, KP - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
tora - Takamichi Akiyama wrote: > Hi, > > There seems room to enhance the usability around a file lock system of 3.0. > > A division runs a file server for its staffs. > 1. A general manger sends an e-mail to staffs 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. 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 opens ..., and blames User A. > > User A did not intend to edit it or even bother anybody else, but just wanted > to SEE it. > > Models > "Look before editing it" model - once used by legacy version control > systems: rcs, sccs. 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? > "Merge after editing it" model - used by recent version control systems: > CVS, Subversion, git. > Current implemention 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. > 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. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
