[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dealing with large collections [Re: URI constraints]


Greg Stein wrote: 

I would not recommend either of those approaches, though I'll certainly
give you the "creative" tag :-)  My thinking:

* it isn't a range because you're asking for specific ordering. if it
  wasn't for that, it would be darned close. the ordering request is
  effectively a "content negotation" much like asking for english versus
  french.


I should have been clear that I wasn't trying to match your search grammar's capabilities (though I think the asc/desc is unnecessary). I was only trying to match the capabilities of getRecentPosts() in the bloggerAPI and the metaWeblogAPI. This assumes ordering by atom:updated:

GET ...
Expect: atom-range
Range: atom -20

206 ...
Etag: asdf
Content-Range: atom 1313-1333/1334

If you get a request for the full resource, you can say "202 your export file is here in 15 minutes" or something. Or just give it a 500.


I still like the idea of a teeny search grammar. Each of the parts of the
above example would just be an XML element in a query.

"Want something more advanced? Ah, we have SEARCH and DASL for you."

My thinking here is that this is the established, already-done way to provide robust, extensible querying. I know that SEARCH/PROPFIND/REPORT/etc don't seem like a big deal to you (or me), but there are *tons* of apps that won't be supporting them for the foreseeable future. I think we should expect that many apps will be taking their existing metaWeblog/BloggerAPI code and adapting. Why not provide a rfc2616-defined way of accomplishing that stuff?

Robert Sayre