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

[Andreas Wuest]

Hi

Crossposting to the OSR-101 list since this message contains Neutron 
relevant paragraphs.

On 11.10.2006 23:59 Uhr, Thomas Comiotto wrote:

>> But what should happen if the client chooses a nonsensical path?
> 
> WebDAV makes no difference but requires the data-path to comply to URI 
> consistency rules (which in turn lots of content servers out there break).
> 
> e.g. data-path (Lenya example)
> 
> /index_en.xml 200
> 
> /index/foo.jpg 200
> 
> /index/ 404 (would be required to be a collection according to the 
> WebDAV specs)

Ok.

> I'd stick to Neutron.

I have no problem using whatever format comes up. It's just that 
somebody said "WebDAV already does what we want, and we should be WebDAV 
compliant". This "somebody" knows who he is...

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).

For example, should a listing for www.foo.org contain 
www.foo.org/research, if the user accessing the listing only has access 
rights to www.foo.org/education. I.e., should the "research" collection 
still be listed, but flagged as non-accessible, or should the server 
only expose collections which can actually be accessed by that 
particular user. This would affect the data-format of such a listing.


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>

(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.

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>

This would result in a single upload endpoint for that collection, 
triggering HTTP requests like e.g.

PUT /education?upload HTTP/1.1
Host: www.foo.org
Content-Type: image/png
X-Neutron-Name: thomas.png

...

Does this all make sense?

-- 
Kind regards,
Andi