[Standards-JIG] JEP-0060: open issues
boyd.fletcher at je.jfcom.mil
Thu Jun 15 06:29:20 UTC 2006
Regarding pubsub node/item ordering, I think part of the confusion is that
many people seem to assume that in pubsub only one person/process/thing
should be writing to a given pubsub tree a single time. We want to broaden
that view to one in which multiple persons/processes/things are writing to a
given pubsub tree at the same time including sometimes to the same node.
Ideally we would like the ability to lock nodes/items for update, but
handling unlocking for dead/dropped connections can be very complex. So a
simple solution that solves many use cases is the use of ordering of
nodes/item and with allowing multiple pubsub CRUD ops in a single XMPP the
complete operation can be made atomic. Relying on well behaved clients is
simply too dangerous for us.
whiteboarding where potentially 1000+ users (we have a requirement for that
many) could have access to the whiteboard in a single session. Without the
ability to enforce ordering on the server there isn't a practical method
that we can think of (and still use pubsub) to guarantee that order of SVG
elements is returned consistently each time. If you did client ordering,
there is no reliable way to store and retrieve the order of items on a given
layer in a whiteboard if multiple people are updating the whiteboard. There
has to be some server based mechanism that says no duplicate ids are found
and that Item A is before Item B and item B is before item C. It is not
possible for the client to "sort" the items after downloading since the item
ids are not monotonically increasing nor could they be in a distributed
environment. The order of items returned from pubsub is the order the items
are drawn on the whiteboard.
So if not ordering then we need some other capability in the specification
that allow atomic operations on a given pubsub tree.
As for being able to specify permissions inheritance in PubSub. I read the
chat logs and there wasn't much discussion on this. I do not understand the
reason of not making this a protocol level configuration option. The client
needs to able to know reliably if the permissions are going to be inherited.
If not, then interoperability between pubsub implementations just went out
Two use cases:
1) whiteboarding: you have 1000 users working on a whiteboard performing
CRUD ops on pages, layers, and items. if the server did not have the ability
to do permissions inheritance them everything a page, layer, item is created
the client must manually set the permissions on the object. this is a time
consuming and expensive process. If the server did this automatically (if
the config param is set), then several unneeded XMPP messages that are sent
to the server would be eliminated. on large servers with lots of active
users and active whiteboard sessions this extra message chatter is a big
deal. We low bandwidth comms like we have, its a show stopper.
2) we are working on a project where several thousand sensors are using XMPP
to update a pubsub tree with status information. the list (names) of the
sensors changes frequently (potentially dozens of times a day). the sensors
connect to the XMPP server, login into a chat room, and post certain
critical alert messages to the pubsub tree (same tree), the users (people
and other computers) are subscribed to a single pubsub tree for all the
sensors. users have no knowledge of the number and names of the sensors. If
pubsub supported inheritance then we can assign dynamic muc room permissions
to the pubsub tree and all the sensors can write to that pubsub tree without
have to be individually configured. BTW in case you are curious the muc room
is used to send group control commands to all the sensors at the same time
and we use the room presence to see which sensors are online. On a given
server and sensor suite there are a dozen plus types of sensors and each
type of sensor has its own chat room and pubsub tree. having a separate
pubsub tree for each node is not possible since the number and names of
sensors (and thus nodes) is not known by the clients beforehand and they
What's the harm of making these optional capabilities that can be discovered
for those folks that need them?
What's the possibility of readdressing these at the next council mtg?
On 6/14/06 1:27 PM, "Peter Saint-Andre" <stpeter at jabber.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> In the Jabber Council meeting held this morning , the Council
> discussed  the open issues I posted about a few days ago. The
> consensus of the Council is provided below...
>  http://www.jabber.org/council/meetings/agendas/2006-06-14.html
> Peter Saint-Andre wrote:
>> In the interest of gaining consensus and moving JEP-0060 along, here is
>> a summary of the open issues regarding version 1.8 of JEP-0060. Let me
>> know if I've missed anything.
>> Oh, and one "meta-issue" is whether to address these open issues in 1.8
>> or in 1.9:
>> 1. Data Forms
>> Get rid of 'access' attribute on <configure/> element?
>> Also get rid of 'type' attribute on <create/> element?
>> Force use of node configuration data form in both cases or just for
>> access model (create 'type' was in 1.7)?
> For both -- use data forms rather than these "hardcoded" attributes.
>> 2. 'node' attribute for <items/> element
>> What should the value of the 'node' attribute be for <items/> elements
>> in event notifications received from collection nodes? Specifically,
>> should it be the NodeID of the collection node (current policy) or
>> sometimes (in the case of transient, notification-only nodes as the
>> generator of the notification) the NodeID of the generating node?
> The value of the 'node' attribute should be the NodeID of the node that
> originated the item. For a leaf node that is obviously the NodeID of the
> leaf node. For a collection node that is the NodeID of the node that
> generated item (*not* the NodeID of the collection node, even if the
> subscriber subscribed to the collection node rather than the originating
>> 3. Handling of configuration-required subscriptions
>> When a subscription to a node must be configured in order to take
>> effect, should we return (1) a success-with-configuration-request
>> (current policy) or (2) a <not-acceptable/> error?
>> Should we recommend (1) but allow (2)?
> As discussed by Ralph on the list, this is mostly an implementation
> issue. However, recommending (1) and allowing (2) seems unobjectionable
> to me so I will add a note about it (that way, implementations that
> can't do (1) will at least know which error to return).
>> 4. Subscription retrieval
>> Should we define a way to retrieve all subscriptions (with full
>> configuration information) in one request?
> No. Figure out a different way to do this. :-)
>> 5. Ordered nodes
>> Should we define a way to enforce order on the items published at a node?
> No. The preferred method is to do this in the item itself (with a
> mechanism yet to be determined) rather than at the service level, this
> will allow for re-use in non-pubsub contexts (e.g., MUC).
>> (And also, it seems, to enforce order on the nodes within a collection,
>> though what that means is unclear to me.)
>> 6. Configuration inheritance
>> Should we define a way to enforce inheritance of node configuration options?
> No. This can be done by setting smarter service-wide defaults, through
> an admin interface, etc.
>> 7. Paging through published items
>> Should we define a way to set the "start item" for items retrieval?
>> And further, should we get rid of 'max_items' attribute and do "paging"
>> using JEP-0059?
> We will probably recommend use of JEP-0059 in version 1.9 of JEP-0060
> for both start_item and max_items, but need to advance JEP-0059 to Draft
> first. Expect a Last Call on that soon.
> Another issue, raised by Matt Tucker but not discussed in the Council
> meeting, is permissions mapping:
> If we address that, I think it will be in 1.9. Or naturally it could be
> done with a non-standardized configuration field (not everything that
> people do with pubsub needs to be standardized in the JEP).
> - --
> Peter Saint-Andre
> Jabber Software Foundation
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
More information about the Standards