On Tue Aug 24 19:26:11 2010, Brian Cully wrote:
I've finally been able to do some work on this, and am close to
sending out a new version. Before I do, however, I'd like to know
if there are any outstanding issues people have had with it. I've
gone through my old mail and have a start on some things:
* Usefulness of notification depth choices
* Access control
* SHIM header issues with both SubID and Collection headers
* Item retrieval on collection nodes
My open issues, having implemented most of this now, include:
- Retrieve subscriptions - should we return all subscriptions
affecting the node (ie, include any which would cause a
notification), or just the "local" subscriptions.
- Access control requirements for adding/removing nodes. (I picked
owner required on collection).
- What does publishing an item to a collection do?
I've covered access control with by using the collection's access
model and adding a note to "Security Considerations" saying it
could be a bad thing to allow, for instance, open access on a
collection node which has closed or authorize children (but this
can also be a useful thing, too).
I did this by validating each node distinctly, so that if you have a
whitelist node inside a collection, an event on that node won't be
seen by subscribers to the collection unless they are able to
subscribe directly. It seemed logical, and easy enough.
I'm on the fence about SHIM headers. I think we need a new one
because of the limitations of the schema, or perhaps we should omit
the "Collection" header when SubIDs are extant because it's
redundant in that case.
I'm not sure it actually is. Are SubID's mandated to be unique across
a service?
In any case, I hate SHIM, so I'd be open to an alternative.
Item retrieval is tricky. I think it's a highly valuable thing for
both client simplicity and access control. It's good to be able to
say "if you can get a notification about it, you can retrieve it in
the same way you subscribed to it." However, the existing schema
for item retrieval allows only one <items/> element in the query
response. If we could allow more than one then it becomes fairly
simple.
I'm not convinced of the need, it seems astonishingly complex - I'd
have to involve recursion, which I'd much prefer to avoid.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
