[Standards] XEP 0254 suggestions

Joe Hildebrand joe.hildebrand at webex.com
Wed Aug 26 14:32:10 UTC 2009

On 8/25/09 4:16 AM, "Mads Randstoft" <mr at wirelessfactory.com> wrote:

> 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".

I'd say just make it an integer, 0-127, like presence priority.

> What happens if a priority is not set? I suggest, based on the above
> that a Default is chosen if none is set.

Just make it 0, again, like presence.

> 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.

Seems reasonable as an optional feature.

> 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.

Has anyone implemented this yet?  If so, let's just leave it.

> 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.

Implementations are always free to come up with their own ad-hoc commands.

Joe Hildebrand

More information about the Standards mailing list