[Standards] XEP 0254 suggestions

[Mads Randstoft]

Title: Signatur

After looking at PubSub queuing for our system, we have desided that this is almost what we need. I have a few suggestions to be discussed before we do an implementation and I will try and move this to Draft or even Final soon. 1) Priority queue. As an added namespaced attribute to <item> (described in XEP-0060) a priority would be set, and in case there are already unhandled (not yet locked) items in the queue, this item is added in a priority queue manner. This gives the following questions. What are priorities? I suggest a list of 5 from "Highest, High, Default, Low, Lowest". What happens if a priority is not set? I suggest, based on the above that a Default is chosen if none is set. Should starvation prevention be implemented? Implementation specific. Should timeout be different based on priority? Implementation specific. 2) Handler & Monitor subscriptions. As an extension of the current proposition, I would like to add "Monitor" subscriptions, that work in the same way, "normal" PubSub (XEP-0060) works, each monitor subscriber gets a normal notification, the component does NOT lock the item to any monitor. So, for each item that is published, any number of monitors are notified, one handler is notified and item is locked to this handler. Since items in a PubSub queue is deleted "quickly" by the handler, Payload must be sent along with notifications, for all monitors to be able to get it without This gives the following questions. How to distinguish monitor and handler? Via subscription options when subscription is done. Should monitor subscriptions be kept when client is offline? Possibly set via subscription options. 3) I suggest renaming subscription option  "pubsub#queue_requests" to "pubsub#max_concurrent_locks" as I belive this describes the purpose better. 4) An ad-hoc command should be added for the component to get a readout of the current queue size (number of items on a named queue at this very moment, locked an not yet locked) this could be implementation specific as well, but s std. could be deviced. -- Med venlig hilsen / Best regards Mads Randstoft mads randstoft java developer wireless factory aps galionsvej 52 dk-1437 københavn k mobile: +45 31 31 96 07 office: +45 70 20 12 92 fax: + 45 32 95 83 02 m...@wirelessfactory.com www.wirelessfactory.dk