[Osr-101] On the semantics of checkout and checkin

[Andreas Wuest]

Hi

Now, this has already been discussed in and out, but AFAICT, all we 
agreed upon was that checkout and checkin are basically shortcuts for 
open+lock and save+unlock, and is therefore optional.

I've recently had another idea though. Namely "servers" which may not be 
able to open a document without locking it.

Think for example about certain distributed filesystems. There, opening 
a file might be connected to acquiring a lock on that file, and no one 
else can open that file until it is closed again.

What I want to say is that there might be servers which can open a 
document without locking, and some others might automatically lock a 
document upon open. This means that checkout can indeed not be replaced 
by open and lock, because open does not work on such servers.

This is also related to the other discussion regarding resources and the 
edit element. Namely that opening a document on such a server as 
presented above might work with locking, but then you can't save to that 
file. In order to be able to later write to that file, you would have to 
open it right in the beginning for writing, which then creates a lock.

Or in other words:

<introspection>
   <resource url="file:///afs/wyona.org/document.xml" name="Some Document">
     <save url="file:///afs/wyona.org/document.xml"/>
   </resource>
</introspection>

might not cut it, because when opening that file for editing, the client 
does not know that he has to open it for writing, instead of simply 
loading it.

<introspection>
   <resource url="file:///afs/wyona.org/document.xml" name="Some Document">
     <edit>
       <open url="file:///afs/wyona.org/document.xml" method="WRITE"/>
       <save url="file:///afs/wyona.org/document.xml"/>
     </edit>
   </resource>
</introspection>

makes it clear for the client what to do. If you want to open it for 
simple reading, you can still use the url provided by the resource 
element, but without a special method.

If you people think I might be badly off on a tangent, please say so. I 
just wanted to reinforce that it might be a good idea to make things 
very explicit, instead of cramming meaning into URLs which are attached 
to some parent element like resource.

-- 
Kind regards,
Andi