[Standards-JIG] Re: pubsub: questions and comments
gaston at jivesoftware.com
Tue Feb 28 19:39:43 UTC 2006
"Peter Saint-Andre" <stpeter at jabber.org> wrote in message
news:4403BB8A.8010006 at jabber.org...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi Gaston, thanks for the questions, and sorry for the delay in replying.
> Gaston Dombiak wrote:
>> 2) The JEP allows to retrieve the default configuration of nodes but
>> is no way to edit the default node configuration values. I think that it
>> would be useful to let sysadmin change the default configuration to use
>> new nodes. And it would help to have this functionality standardized in
> Hmm, SysAdmin use cases, eh? We avoided those in JEP-0045 (perhaps that
> was not a good idea), which is probably why we don't have any in
> JEP-0060 either. Could we perhaps add this in version 1.9?
It's fine with me. :)
>> 3) Some nodes may require that new subscriptions be completed by setting
>> subscription options. However, there is no field in the node#conf form to
>> specify if subscription options are required. Should we add this field to
>> the form so it's standardized?
> I think a service should be smart about when to require configuration of
> subscription options (e.g., depending on the node type and access model
> and such), thus shielding the node owner from having to decide. I'm not
> 100% sure we need a node configuration option for this. What are the use
> cases for when a node owner would need to toggle this?
Hmm, I haven't realized that this option could be related to node types +
access model. Anyway, I think that making mandatory to configure
subscriptions may depend on things out of the scope of pubsub (i.e. other
business rules) so the service can propose a default value based on an
optional smart logic and let the owner override the default value. I usually
like not-locking solutions and let users configure the application as they
>> 15) This questions is actually related to the "how to build the 1-n
>> relationship between affiliations and subscriptions" problem. When a user
>> creates a new node, the user becomes the node creator but also the node
>> owner. Since the <create> element does not specify any subscription JID,
>> both the new affiliation of type "owner" and the new subscription with
>> status "subscribed" are created for the full JID of the user. Having the
>> full JID of the user as the node owner is not very convenient for IM
>> since that means that they can only administer the node using the
>> resource. IMHO, we should also include the "owner" attribute to the
>> element so that the affiliation is created using the owner value and if
>> was defined then the sender of the IQ packet is used instead. What do you
> Hrm. Yes, we probably need to make the owner JID explicit, because
> truncation of a (seeming) full JID to a bare JID can be unreliable.
Agreed. More about this in
Let me know if you want to discuss this by IM.
> And the bonus question!
>> 16) In section "9.2 Subscribing to a Collection Node" we found the
>> following text: "A service MAY allow an entity to subscribe to a
>> collection node twice, once with a subscription of type "nodes" (to
>> receive notification of any new nodes added to the collection or the
>> entire tree) and once with a subscription of type "items"". If the
>> pubsub service supports many subscriptions to leaf nodes then
>> shouldn't we allow users to subscribe to collection nodes many times
>> when subscription is of type "items"?
> Sure. The point here is that the service should allow both "nodes" and
> "items" subscription types -- it is not meant to limit the number of
> "items" subscriptions (as described elsewhere in the JEP).
Ok, so entities may have many subscriptions of type "items" but only one of
type "nodes" with a node collection. Is that correct?
More information about the Standards