Re: URI constraints

[Greg Stein <gstein@xxxxxxxxxx>]

On Mon, Oct 11, 2004 at 02:51:18PM -0400, Robert Sayre wrote:
> Greg Stein wrote:
>...
> >    https://www.blogger.com/atom-1.0/blogs/12345678/
> >
> >POST'ing to that resource would create a new blog post. Running PROPFIND
> >on it would return "all" the posts (non-scalable, so I need to think a bit
> >on that one). The PROPFIND results contain URLs for the posts within that
> >collection (where the collection represents the blog). 
> 
> I think this is where we have a big culture clash, which is kind of 
> humorous considering all GETs have previously been tunneled through POST 
> in blogging APIs.
> 
> Why can't we define the response to a GET on the collection resource?

While WebDAV avoids defining a response for *generic* collection
resources, there is a "typical" response: the HTML index that you noted.
Subversion servers hosted thru Apache have a built-in HTML or XML
response, and most mod_dav installations use Apache's builtin directory
index for the files in the directory.

That said, this WG could define the GET response for that *specific* type
of collection resource. (maybe this is what you meant?)

> The typical DAV "html index" behavior doesn't seem real useful. I was 
> thinking the WG could define the collection's response to a GET as 
> equivalent to some prefab PROPFIND request (probably Depth: 1) the WG 
> agrees on.

A DAV multistatus response would be possible, but we could also consider
something "less wordy".

> >There is an open question for what to do with the blog that has 100,000
> >posts in it. That would be a scary-huge PROPFIND result (legal, if a bit
> >expensive; could be about a 20 meg response).
> >
> 
> What's stopping you from having child collections? But yes, in general, 
> we have a query problem.

Child collections would be possible, sure, but would the client know they
were supposed to recurse into them?

My first reaction would be to define optional elements for a PROPFIND
request. Most servers would not recognize those elements, but if they
*do*, then it could take better action. For example:

  PROPFIND /atom-1.0/blogs/12345678/ HTTP/1.1
  Host: www.blogger.com
  ...
  
  <?xml version="1.0" encoding="utf-8" ?>
  <D:propfind xmlns:D="DAV:">
    <A:limit xmlns:A="atom-namespace">20</A:limit>
    <D:prop>
      <D:getlastmodified>
      <D:getetag>
    </D:prop>
  </D:propfind>

I'd think that two types of limits would be reasonable: max-count and
since-this-date.

Note that DASL would be another possibility for retrieving entries from
one of Atom's various collections. It defines a way to limit the results
(see section 5.17 of Julian's lastest draft[1]). I feel that the query
stuff is a bit much, but it is at least some prior work.

Cheers,
-g

[1] http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-07.html