[Osr-101] Re: [Phoenix] Yanel sitetree and upload support

[Andreas Wuest]

Hi Thomas

On 12.10.2006 23:19 Uhr, Thomas Comiotto wrote:

> Hi Andi
> 
>>
>> I have no problem using whatever format comes up. It's just that 
>> somebody said "WebDAV already does what we want,
> 
> No, it doesn't.

I believe that for the purpose of collection listings, we could get away 
with it. Although it is not my favourite!

>> If we want to have Neutron specify such a collection listing format, I 
>> am all for it. Though we first should settle some aspects. Especially, 
>> how much data of the actual hierarchy (or whatever the server makes of 
>> it) should be represented. E.g., should it be possible to list 
>> non-accessible collections (where collections are used in the WebDAV 
>> sense here).
>>
> 
> I think filtering (recursive) collections would be convenient but might 
> lead to difficulties with regards to displaying a tree for the 
> collection. I'd include all items and introduce a AC related status 
> flag. Clients can apply a filter (or display items greyed out, 
> whatever). As long as items only point to intospectables even the most 
> paranoid will still get some sleep I think.

Ok. So our listings will basically expose simply all information, 
augmented with some flags which may e.g. indicate unaccessibility, etc. 
The client can then decide how it wants to present this information to 
the user.

> The crucial point in my view is locking: WebDAV for instance requires 
> all members of a collection (including "sub-collections") being locked 
> when a single memeber is locked. This in fact hampers concurrent access 
> to members of recursive collections to a significant degree. User B must 
> be able to edit foo/bar/andi while user A is editing foo/bar.
> 
> Now A might decide to rename foo/bar to /foo/thomas while foo/bar/andi 
> is still checked out by B. This can be solved by either preventing A  
> from doing so (by throwing an exception at her that foo/bar/andi is 
> currently locked/checked out), or by requiring the server to provide for 
> sync'ing trees (if necessary). I'd opt for the former, because this also 
> leaves it open for the server to try sync and throw exception if unable 
> to sync (or if sync'in is unimplemented). This concerns all remote 
> methods BTW.

+1

> Note that Lenya deals with the above by throwing a "document does not 
> exist" exception at B when attempting to checkin her changes!! (you 
> know, it dosn't even throw a "document does not exist anymore/renamed" 
> exception..). This means that B will loose all work done in this 
> situation. The funny thing is that, at least at UZH, nobody ever 
> complained about this. The obvious reason is that there's usually a 
> single content author responsible for a single web site, so trees seldom 
> run out of sync. But I'd hesitate considering this approach solid to say 
> the least.

Yeah, though there may be different setups, and we should cater for such 
situations.

>> I am open to any ideas. An initial proposal would be (for a collection 
>> listing at http://www.foo.org/education):
>>
>> <collection xmlns="http://www.wyona.org/Neutron/1.0" name="education">
>>   <collection name="winter" uri="winter?collection"/>
>>   <collection name="summer" uri="summer?collection"/>
>>   <resource name="index.html" uri="index.xhtml"/>
>>   <resource name="people.html" uri="people.xhtml"/>
>> </collection>
>>
> 
> I still like the idea of using the term collection for sync'ing remote 
> methods: open a member, open all members (WebDAV style but without URI 
> namespace limitations) - not for representing a resource hierarchy. I'd 
> rather use the notation of a  <sitetree> for that.

You mean:

<sitetree xmlns="http://www.wyona.org/Neutron/1.0" name="education">
   <sitetree name="winter" uri="winter?sitetree"/>
   <sitetree name="summer" uri="summer?sitetree"/>
   <resource name="index.html" uri="index-introspection.xml"/>
   <resource name="people.html" uri="people-introspection.xml"/>
</sitetree>

> Otherwise I think this makes sense.

Ok. :)

>> (The topmost collection element does not contain a "uri" attribute 
>> because the client should know what he has just requested. Although if 
>> wanted, it could be introduce, but I think this would be redundant).
>>
>> In order to see the contents of the "winter" collection, you would 
>> subsequently have to retrieve the listing at 
>> http://www.foo.org/eduction/winter?collection.
>>
>> I am not sure where the URIs of the resources should point to. To the 
>> source representation of the resource, to the human viewable 
>> representation of it, or to the resource's introspection document.
> 
> To the introspectable or NAR URI.

Ok.

>> Also, in such a setup, if we use it for resource upload, the server 
>> should be able to handle PUT or POST requests to 
>> http://www.foo.org/education/thomas.png, if the collection listing 
>> above was used for the resource upload dialog. I.e., upload of new 
>> resources would be based on the URI given for a specific collection. 
>> OTOH, one could also introduce a special "upload" URI, accompanied by 
>> a name header field requirement in the spec. E.g.
>>
>> <collection name="education" upload="education?upload">
>>   ...
>> </collection>
> 
> Yes. This would have to be extended by creating resources based on 
> content templates (maintained by the server). Further on, new xml-based 
> resources might adhere to datatype requirements (only a set of datatypes 
> allowed in collection X).

Mhhhhm, I am not sure if the sitetree would be the correct place to 
carry information about how new documents can be conceived. But this 
lead me to a different idea from the one above.

You know that we can have multiple resources inside an introspection 
document (commonly called "fragments"). They were originally introduced 
to be able to point to the various fragments which make up the single 
page against which the introspection document is linked (e.g. a page 
containing a course listing, which consists of an introductionary text 
and the actual listing; the introduction text is editable separately, 
because it should only be editable by the department chair, whereas the 
course listing can be edited by the individual teachers).

<introspection>
   <resource name="Introduction">
     <edit>
       <open uri="introduction.xml?editopen"/>
       <save uri="introduction.xml?editsave"/>
     </edit>
   </resource>
   <resource name="Courses">
     <edit>
       <open uri="courses.xml?editopen"/>
       <save uri="courses.xml?editsave"/>
     </edit>
   </resource>
</introduction>

Why not extend the concept of introspection documents to not only be 
linked against individual pages, but also be used for collections (in 
the WebDAV sense, and, I believe, at the same time this would also fit 
the UZH collection definition (documents which belong somehow together)).

Assume we have a hierarchy

foo/
   bar/
     duck.xml
   thomas/
   index.xml
   people.xml


Then we could link an introspection document against www.foo.org/foo, i.e.

<introspection>
   <introspection name="bar" uri="bar-introspection.xml"/>
   <introspection name="thomas" uri="thomas-introspection.xml"/>
   <resource name="Index">
     <edit>
       <open uri="index.xml?editopen"/>
       <save uri="index.xml?editsave"/>
     </edit>
   </resource>
   <resource name="People">
     <edit>
       <open uri="people.xml?editopen"/>
       <save uri="people.xml?editsave"/>
     </edit>
   </resource>
<introspection>

In order to see the contents of the bar/ collection, you would then 
request bar-introspection.xml.

This way, we could eliminate the need for separate sitetree documents, 
and solve everything via introspection documents. This would give us the 
advantage that, as soon as we have specified the <new/> element, looking 
at the "sitetree" represented by the introspection document would also 
give us information about how to create new documents (i.e. which 
templates to use and which datatypes are accepted).

WDYT?

-- 
Kind regards,
Andi