On 24-Nov-2009, at 11:29, Ralph Meijer wrote:
> If this is not what the schema says, then it should be changed to
> reflect what I just said. There can be at most one <items/> element
> inside <pubsub/> (and no other elements in the same namespace).
I can't really read XSD, but it appears you are correct that this is
what it says. My own preference should be obvious in my choice of
implementation (i.e., multiple <items/> elements). The reason I prefer this is
that in practice when dealing with XML already, you're dealing with
zero-or-more elements matching a given path; whether one uses XPath, DOM, or
any of the multitude of XML processing libraries, so it's relatively easy to
simply add another element to a given path and handle it. The alternative -- at
least when trying to preserve the synchronous request semantics of get-items --
is adding a new element which can contain multiple <items/> elements. This
doesn't have much advantage that I see, and has the disadvantage of arbitrarily
altering the path to match when dealing with collections, complicating code and
necessitating the client's understanding that a node is a collection. In my
approach, clients can be dumb about node types and only need to handle the case
of more than one <items/> element, which, as mentioned, is inherent in existing
XML processing libraries.
> Maybe RSM is indeed a better solution. I'm just curious how well it
> works for retrieving one item at a time (likely when items are Atom
> Entry documents).
To be fair, I need to read RSM with an eye to this functionality to
make sure it works, but if it does, I would prefer using RSM to empty results
from get-items. For retrieving single items you're certainly going to incur a
lot of overhead on fetching all the items from a node. However, this can be
ameliorated in a number of ways: get-items without bodies, then issue separate
requests for the item ids you're interested in; have the server decide the
appropriate number of items to batch; and probably others.
-bjc
