On 10/3/2009 7:58 PM, Brett Zamir wrote:
On 10/3/2009 1:06 AM, Mads Randstoft wrote:
Brett Zamir<[email protected]> Wrote:
While attributes are being added to<item/>, would there also be some
way to add meta-data about the node to the event as well, e.g.,
pubsub#num_subscribers (the number of subscribers to the node) or
pubsub#title (human-readable node name)? I know it can be retrieved
separately, but this seems it could be useful to be able to get back
together...
I would say this could be added as a configuration option for node?
Adding some data as meta data to a published item?
As I imagine the system, it would be sort of individual and discoverable
implementation specific.
That sounds like an interesting approach... Another (which could
co-exist with your node configuration idea if the latter were treated
instead as being obtainable under the new retrievable default
subscription options) might be to let it be decided via subscription
options. A client which wished to use the meta-data could therefore
get it delivered in a way which suited its interface options and user
preferences.
In either scenario, the option could be of type list-multi, to allow
flexible specification of exactly which meta-data was desired.
This might be both more powerful and flexible, in allowing clients and
users to come up with their own use of meta-data as perhaps not
anticipated by the server administrators, as well as more economical
than sending all meta-data automatically if there was no desire for it
(which could add up to a lot if it is being attached to each
notification).
To mitigate the fact that at least some meta-data is unlikely to
change (e.g., pubsub#creation_date indicating when the node was
created) and could be discovered immediately after initial
subscription (currently by a meta-data discovery request), perhaps
even the subscription confirmation could be made to return such fixed
meta-data (as child XML) so that clients could be aware of node
support for such fixed meta-data (without making an extra request or
needing to receive the meta-data with each notification delivery). The
clients would thus be able to retain and associate such non-altering
data corresponding to each node to which the user subscribed, so that
they would only need to configure their subscription options to
receive the more frequently changing meta-data which they desired
(e.g., #num_subscribers).
There would be one additional requirement which I think would be both
economical and semantically necessary to add to this: an XML element
like <node/> to contain any meta-data about the node in the item
notification. It would not be appropriate to the content model to attach
to <items/> or <item/> since the information is not about the item.
I imagine it should even be appropriate for other notifications besides
'items' ones to allow such a <node/> element for meta-data (i.e., for
item deletion, node purging, node configuration change, or subscription
approval/denial/cancellation/lease end).
Brett
