[Standards] XEP 0254 suggestions

Mads Randstoft mr at wirelessfactory.com
Tue Aug 25 10:16:50 UTC 2009


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

Wireless Factory Aps

	

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
mr at wirelessfactory.com <mailto:mr at wirelessfactory.com>
www.wirelessfactory.dk <http://www.wirelessfactory.dk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090825/c0dbe439/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.jpg
Type: image/jpeg
Size: 4540 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090825/c0dbe439/attachment.jpg>


More information about the Standards mailing list