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 Conversion OpenOffice Vs. Jacob
Hi Kermit, 2009/6/19 qkm qkm > > > 1. Now I need the local invocation in local call. Then I use JODConvert > > > to be invoked by myApplication and translate the invocation into TCP to > > > OpenOffice. Could any approach I can invoke OpenOffice directly? > > > > Not sure what you mean? Maybe that your app is not written in Java, > > and you'd like a library that you can invoke directly in your app's > > language? In that case, it would help if you tell us which language > > you're using. > > [Kermit] Now I use Java to invoke JODConverter to make a TCP connection > > with OpenOffice. Could you invoke OpenOffice directly by Java,does it > > OpenOffice UNO can be invoked by Java locally? > > Still not sure what you mean by invoking it "locally"? OOo is written mainly in C++, you can't invoke it directly from Java. To invoke native libraries from Java you'd need to write JNI wrappers, but there are no conversion functions exposed by OOo as simple library calls anyway. The way it works is that you start OOo in listening mode, and then you connect to OOo from your Java app using either a TCP socket or a named pipe for inter-process communication. Read the OOo's guide for more info: http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Starting_OpenOffice.org_in_Listening_Mode http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Opening_a_Connection JODConverter simplifies all of this by providing a simpler and more intuitive API. Kind regards Mirko - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document Conversion OpenOffice Vs. Jacob
Hi Mirko, Thanks for your quickly response! My answer is as below. Best Regards, Kermit On Fri, Jun 19, 2009 at 4:10 PM, Mirko Nasato wrote: > Hi Kermit, > > 2009/6/19 qkm qkm > > > >Now I am trying to design the conversion from > PDF/Word/Excel/Powerpoint > > to HTML format. Currently I have a quick look about both OpenOffice and > > Jacob, both of them seem can meet my requirement. But I have the > following > > questions, could you answer them for me? > > 1. Now I need the local invocation in local call. Then I use JODConvert > > to be invoked by myApplication and translate the invocation into TCP to > > OpenOffice. Could any approach I can invoke OpenOffice directly? > > Not sure what you mean? Maybe that your app is not written in Java, > and you'd like a library that you can invoke directly in your app's > language? In that case, it would help if you tell us which language > you're using. > [Kermit] Now I use Java to invoke JODConverter to make a TCP connection > with OpenOffice. Could you invoke OpenOffice directly by Java,does it > OpenOffice UNO can be invoked by Java locally? > > > > 2. How about the conversion peformance of OpenOffice? Any one has the > > test result? > > Performance greatly varies depending on the type and size of your > documents. See http://www.artofsolving.com/node/30 for a few examples. > You should do your own tests with samples representing your typical > usage. [Kermit] Thanks! > > > Kind regards > > Mirko > > - > 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 Conversion OpenOffice Vs. Jacob
Hi Kermit, 2009/6/19 qkm qkm > > Now I am trying to design the conversion from PDF/Word/Excel/Powerpoint > to HTML format. Currently I have a quick look about both OpenOffice and > Jacob, both of them seem can meet my requirement. But I have the following > questions, could you answer them for me? > 1. Now I need the local invocation in local call. Then I use JODConvert > to be invoked by myApplication and translate the invocation into TCP to > OpenOffice. Could any approach I can invoke OpenOffice directly? Not sure what you mean? Maybe that your app is not written in Java, and you'd like a library that you can invoke directly in your app's language? In that case, it would help if you tell us which language you're using. > 2. How about the conversion peformance of OpenOffice? Any one has the > test result? Performance greatly varies depending on the type and size of your documents. See http://www.artofsolving.com/node/30 for a few examples. You should do your own tests with samples representing your typical usage. Kind regards Mirko - 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
