[Standards] Standards Digest, Vol 69, Issue 17

Mads Randstoft mr at wirelessfactory.com
Thu Aug 27 11:23:54 UTC 2009

>> 1) Priority queue.
>> As an added namespaced attribute to <item> (described in XEP-0060) a
> I'd say just make it an integer, 0-127, like presence priority.

Yes, that is also a possibility.

Will it be best to add a namespaced attribute or an element?

Publish (With priority) Attribute style?
<iq from='engine.shakespeare.lit' id='pub1'
to='workflow.shakespeare.lit' type='set'> <pubsub
xmlns:pri='http://jabber.org/protocol/pubsub#queue_priority'> <publish
node='a290fjsl29j19kjb'> <item id='ae890ac52d0df67ed7cfdf51b644e901'
pri:priority='12'> <example xmlns='urn:xmpp:example'>payload</example>
</item> </publish> </pubsub> </iq>

Publish (With priority) Element style?
<iq from='engine.shakespeare.lit' id='pub1'
to='workflow.shakespeare.lit' type='set'> <pubsub
xmlns='http://jabber.org/protocol/pubsub'> <publish
node='a290fjsl29j19kjb'> <item id='ae890ac52d0df67ed7cfdf51b644e901'>
<example xmlns='urn:xmpp:example'>payload</example> </item> </publish>
</pubsub> </iq>

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

Problem here is that 0 is highest priority in most implementations, I
would want for unprioritized items to be "medium" of some kind...

Perhaps this should be a configuration possibility when creating the
queue, setting default priority.

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

Should this be detectable by feature discovery? Or when requesting
subscription (either giving error for not supporting options when set,
or if requesting options, asking for the worker/monitor option?

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

>> This gives the following questions.
>> How to distinguish monitor and handler? Via subscription options when
>> subscription is done.
> Yes.

>> 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
> Has anyone implemented this yet?  If so, let's just leave it.

According to Peter Saint-Andre, he is not aware of any implementations.
I will leave it open for now.

Problem comes with the monitor option, because the field is invalid for
monitors, so it should be optional and not required. Alternativly it can
be ignored

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090827/a270a632/attachment.html>

More information about the Standards mailing list