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

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


On Oct 11, 2004, at 1:38 PM, Robert Sayre wrote:

I fully agree with your assessment of the problem for entries, but I don't think that approach is a natural way to browse for templates, pictures, categories, users, etc.

The response to "max-count" and "since-this-date" would be great in the feed format we have now, along with prev/next. The feed format isn't such a great way to browse for other resources,

I don't follow you here. I've understood that we were talking about general ways of listing collections of resources (of whatever type).

or to find that entry your wrote in 1999 but haven't modified in ages, especially if I'm not exactly sure what I'm looking for.

--entries
   --2004
   --2003
   --2002
   --2000
   --1999
     --sep
       --13

The server would be free to organize this however it wanted (or leave it up to the user... if feeling adventurous...), so if I had written 1000 posts on Sep 13 1999, I might find more collections in there. Does this make sense?

I think so. On the upside, this approach gives control to the server over how to slice and dice. On the downside, it seems this gets the server into the "presentation" business: figuring out how to subdivide that 1000-entry day in a way that the user would want to browse through.

Clients are (hopefully) going to have all kinds of creative ways for users to browse through their collections. If the server determines the browse hierarchy, it's harder for clients to do that.

So, there are at least two ways a client wants to interact with the server's list: in one case, it doesn't want to keep any state, it just wants to immediately display lists that are given by the server ("server determines presentation"). In the other case, it wants to build a local model of the server-side state, and it wants to use Atom to sync up. First of all, are these both realistic scenarios? Can we hear from some client developers?

Here are some thoughts on how well each model (query language vs. collection hierarchy) supports each of these approaches.

If there is no query language, syncing is harder, since clients have to trudge through the collection hierarchy, but it is workable.

On the other hand, if we have a query language, we have a lightweight mechanism for the syncing process (clients can use a query for "last-modified > last-sync-time"), and clients may be responsible for presentation. This forces servers to support whatever queries are spec'd--but surely we could settle on a modest enough query language that this wouldn't be a burden. I'd stand by Greg's stake in the ground and stick to comparisons against one field. As for operators, just less-than, greater-than, less-than-or-equal, and greater-than-or-equal should be sufficient. And of course we need a specification around partial responses.

I've been thinking about this a bunch, and I'm still not sure which one is better. I know which one is better for my needs, but we haven't heard much from client developers. How do clients want to interact with large sets of items?

Thoughts?

Ezra