On 11/8/09 9:48 PM, Brett Zamir wrote: > On 11/8/2009 5:26 PM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> My apologies for the delayed reply. >> >> On 10/2/09 12:46 AM, Brett Zamir 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 don't see the logic of this -- you want to include meta-data about the >> node in an element that has information about a specific item? >> > > I don't think it makes sense as a part of <item/> (nor as part of the > payload within <item/>) but a sibling of the <event/> in the <message/> > that delivers the item.
Why not just send a plain old message with this information, whenever it changes in some materially interesting fashion? Heck, you could set up a metadata node about node (uh-oh, what if someone wants to know how many people are subscribed to the metadata node? ;-). That way we wouldn't need to define new subscription config options, which IMHO are going to appear complex to your average user. > It is, for example, wasteful to have to make a > separate query to know the number of subscribers for the node that just > delivered the item (our client would like to indicate this), but a > delivery of a news item would be an opportune time to be given an update > on the sending leaf node's variable meta-data I don't deeply disagree, but I don't see a lot of people on the list jumping up and down with excitement. It seems to valuable for your application so I don't want to quell your enthusiasm, but I want to make sure it is of more general interest before we add it to the spec. > (or possibly also > meta-data on the collection node containing the leaf node for which the > item was delivered)--maybe something like this: > > <message> > <event><items>...</items></event> > <node type="leaf" > xmlns="http://jabber.org/protocol/pubsub#meta-data";><field > var="pubsub#num_subscribers"><value>121</value></field></node> > <node type="collection" > xmlns="http://jabber.org/protocol/pubsub#meta-data";><field > var="pubsub#num_subscribers"><value>345</value></field></node> > </message> The spec currently says that metadata is sent (in disco#info replies) using x:data forms and service discovery extensions. It seems that you are recommending a new or hybrid format. > Some meta-data I think would make sense to deliver exclusively at the > time of a successful subscription (e.g., the value of > pubsub#creation_date delivered inside a <subscription/> element from > either an IQ response or as part of a subscription approval message > where approval was required), but other information like > #num_subscribers would be of potential use to update more frequently (it > is to us at least). Thus the appeal, perhaps, of a metadata node. > I suggested elsewhere in the thread that a (list-multi) option could be > added to subscription options which could provide choices of which > meta-data would be delivered in events, so not every subscriber/client > would need to get this information, but the delivery of meta-data could > have default values so a generic application would know which > information was typically shared to clients. Right, but adding more subscription config options scares me more than defining a metadata node. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
