Jan Holesovsky wrote: >> 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?) Yes, we got crash reports for such cases. We already made the code more robust, maybe even robust enough so that we will crash only rarely nowadays. But at least the document can become unusable in case it contains embedded content like e.g. objects. This will lead to data loss because then the document can't be saved anymore. Bad user experience.
> 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. That won't help if you try to read something that isn't there anymore because the file has been overwritten. The document will quit service. >> 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. I wouldn't accept any underdone implementations - it doesn't help really. File access is one of the worst places to make experiments and allow users to shoot themselves into their legs. >> 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... Are you sure that "the competition" unlocks the file completely when it shall be opened from several instances? I doubt this. Simple test: If I open a file in Word I can't overwrite or delete it. If I open the same file again in another Word instance I get a notification that the file is in use and I have three options: - open the file read-only - create a copy and merge later (that's the thing I recommend for OOo) - wait for a notification when the file is available again so that I can merge and save directly (Word uses some tricks to achieve that). The lock of the file is never removed! >> 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. Well, I could agree if you implemented something completely new, but here we are talking about something that the competition has for years. Why not implementing it completely or at least sufficiently if it is known already that it could be done better than just having the basic steps? Doom was a cool game 10 years ago and you could have get credits for a Doom clone 10 years ago. But if you write a new Doom clone today people will most probably think that you are mad. So why should one implement something that is known to be insufficient since years? Why not doing the "real" stuff? >> 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. And more over there is no API *below* osl that works on all platforms. So it's quite unlikely that osl will get such an API. Where is the problem with reopening the file? So - try to open the file - if it can't be opened for writing open it read-only - if the user requests write access offer to create a copy of the file and try to merge it back when the user wants to save When you want to save - try to open the "real" file for writing - if it works merge the files and save the merged document - if it fails offer a way how the user can maintain his local copy until the file is available again If users wanted to have more sophisticated sharing functionality we would need a server that mediates between the users or at least some communication means about synchronized explicit locking/unlocking (the latter means creating a local copy and releasing the original file) so that merging/storing can work always. >> 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. That's where the server comes into play. It lets each client think that each of them can save at any time and manages everything internally. The server can be just a file server or even an application with an API that merges internally. In case of OOo "the server" can even be one of the OOo instances - provided that they have a TCP/IP connection between them. But of course a "real" server would be more reliable. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
