Hi Matthias, Thank you for the valuable feedback! Helps me to sort the ideas. (I've merged your answers into one mail - I hope it's OK.)
On Monday 08 January 2007 14:13, Mathias Bauer wrote: > > The lock()/unlock() here would prevent the other OOo instances from > > changing the document while one of the instances works. Please, does a > > functionality like this already exist in OOo? I would prefer not to > > reinvent the wheel ;-) > > This algorithm looks weird. It seems that you don't want to lock the > file before you save it. Yes, I don't want to have the document locked during the editing, that's right. But only for the documents that are explicitely marked as 'shared'; and I still want to have the file descriptor open as it is now. > But then the document can become modified by > other applications or even deleted by the user while it is still edited > in an OOo instance. This will let OOo crash in many cases. Please remember that no locking was the default until 2.0 (http://www.openoffice.org/issues/show_bug.cgi?id=29425) so I guess if this were a real problem, we would have had some crashreports already. (Or do we have them?) And IIRC - while the file descriptor is still open, the operating system (or at least Linux) does not unlink the file for the process that owns the file descriptor - but I can be wrong of course. > This means > that the way OOo opens documents must be changed: first every file must > be copied and the copy must be opened. When the file is saved you can > try to acquire a lock and proceed as outlined above. After successful > save the file must be copied again. I'd really like to avoid this; but maybe the future will show it is inevitable, and we will have to protect the user from shooting herself into the leg. > IMHO concurrent access without a server managing the access is only of > limited use and I'm not sure if the little gain in functionality is > worth the effort and the pain you put on users if things don't work as > expected. Unfortunately, the company users want it :-( Even the competing product does not solve this feature perfectly & strongly encourages usage of a real database when there a is big amount of concurrent accesses, but that's life... [ Second mail follows ] > I'm not sure if concurrent access for documents is a good idea. > Currently our merging is not perfect and you will have a lot of > disappointed users. For me this is doing the second step before the > first. Without a better merging we can't offer concurrency. I am a fan of incremental improvements ;-) So if the merging is not 100%, the users will tell us & we'll be able to fix that. I cannot do analysis of all the corner cases; all I know is that the merging works well enough for basic work. I will improve it in the next iteration based on the feedback if it's not sufficient. > But maybe I'm too pessimistic. Perhaps it doesn't work perfect in > competitive products also and people are happy with what they get?! Right, http://office.microsoft.com/en-us/assistance/HA010130571033.aspx says that - it even lists all the features that will people miss after switching to shared workbook. > Besides that I don't think that something must be changed in osl. We > just have to change our way how we interpret the results from openFile. Unfortunately it must be. I don't want to open the file again, I just want to set/clear the lock, and there's no API for that in osl. > If a file can't be opened for writing we currently decide to open it > "read only" - but that happens somewhere in the framework code. We > could also allow editing. But then we must remember that we are not the > "owner" of the file when it shall be saved. And we must be able to deal > with the situation that we can't save the file as it is still opened by > somebody else. Both seems to be doable. 'can't save the file' is the point. The ability of the other instance to save is a pre-requisite for the feature. I don't see a way around - if just one of the instances can save, it's not a _shared_ worksheet. Regards, Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
