[Standards-JIG] Re: pubsub: questions and comments

Gaston Dombiak 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 
>> there
>> 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 
>> for
>> new nodes. And it would help to have this functionality standardized in 
>> the
>> JEP.
>
> 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 
>> the
>> 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 
see fit.

>> 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 
>> users
>> since that means that they can only administer the node using the 
>> specified
>> resource. IMHO, we should also include the "owner" attribute to the 
>> <create>
>> element so that the affiliation is created using the owner value and if 
>> none
>> was defined then the sender of the IQ packet is used instead. What do you
>> think?
>
> 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 
http://mail.jabber.org/pipermail/standards-jig/2006-February/010066.html. 
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?

Thanks,

  -- Gato 






More information about the Standards mailing list