Hi Mathias, On Wednesday 10 January 2007 11:44, Mathias Bauer wrote:
> > 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. Interesting. Can you please send me a step-by-step description how to reproduce this with locking turned off (unset SAL_ENABLE_FILE_LOCKING). That would be extremely helpful. > > 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. 'isn't there anymore' is quite relative in this context. One process can unlink the file ('it isn't there anymore'), while it's still available for the other process that opened it before the unlink, and still hasn't close it. > 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! Excel is the program to test. Try again with a worksheet - it gives you similar choices after you try to open it in the second Excel instance. And then turn on the shared workbook functionality (Tools -> Share Workbook). You'll see that now no locking is involved, anyone can open and save it without any additional warning. > >> 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? What exactly do you mean? Niklas just wrote that merging works sufficiently (which is the same that my tests showed). Am I supposed to spend half a year testing whatever works and what does not, another half improving the latter, and then come up with the shared worksheets in another half a year? Sorry, but my employer wouldn't pay this - they want to see the shared worksheets. If they see that there are limitations in the merge, they'll allocate more time to fix that. > 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? Heh ;-) The "real" stuff here is to say the customer: "Shared workbooks are not what you really want. They were designed 10 years ago when there was no application that could help you to design a database easily. You really want a database. Dedicate one server for that, learn this and that, etc." Can we do that? No. > >> 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. Really? fcntl() on unx & Mac OS X, http://msdn2.microsoft.com/en-us/library/aa365203.aspx on Win32, what else? > 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 Sure, that would be nice if it was possible [and I'd appreciate pointers to the code where I could hook this if I'm wrong]. Unfortunately I did not find a better place than ScDocShell::Save() and ScDocShell::SaveAs(), see http://svn.gnome.org/viewcvs/*checkout*/ooo-build/trunk/patches/src680/shared-worksheets.diff?rev=8553 [proof of concept implementation modulo the locking], method LoadAndMergeSharedWorksheet(). Later than in Save() and SaveAs() methods, various transformations happen before the 'open the "real" file for writing' starts, and of course after the transformations it's too late to merge. > > '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. Sure, I don't want to develop a new database engine, just the Shared workbooks ;-) Regards, Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
