[Standards-JIG] JEP-0060: 1.8pre12

Ralph Meijer jabber.org at ralphm.ik.nu
Wed Apr 12 18:37:56 UTC 2006


On Wed, Apr 12, 2006 at 09:18:52AM -0600, Peter Saint-Andre wrote:
> [..]
>
> > - In the #owner namespace, we have 'affiliates', where the bare
> >   namespace has 'affiliations'. Is that intentional?
> 
> Yes, it was intentional. But if it's confusing, we can make them
> consistent. My thought was that a user has affiliations, whereas a node
> owner is managing not his or her own affiliations but the entities that
> are affiliated with the node (i.e., "affiliates").

I don't find it confusing, they /are/ conceptually different views, one
from the p.o.v. of the user for all nodes at that service, the other for
all affiliates of a particular node. However, you are not really dealing
with the affiliates, but managing their affiliations. See also my
comments about subscribers vs. subscriptions below.

> [..]
>
> > - I think we lose the ability have the owner manage subscriptions.  This
> >   could be readded by introducing the subscriptions element in the
> >   #owner namespace. I suppose if the naming of 'affiliates' was
> >   intentional, you could name this 'subscribers'.
> 
> Yes, that ability was lost. Do we need it? If so, we can add it back in.

First off, 'subscribers' might not be a good idea. Any JID can have
multiple subscriptions, and you would have to introduce another layer in
the protocol:

  <subscriptions>
    <subscriber jid='user at example.com'>
      <subscription ... />
      <subscription ... />
    </subscriber>
    ...
  </subscriptions>

Just managing loose subscriptions is probably easier.

The functionality could be viewed as having two parts:

- Getting the list of subscriptions to a certain node.
  
  Unlike 1.7, there is now no way to do this. I think it is important
  to have protocol for this.

- Modifying the list of subscriptions to a certain node.

  Here, you can use <subscribe/>, <unsubscribe/> and <options/>
  unmodified. The service just needs to check the authorization
  properly. However you don't have batch processing.

Compare <owner:subscriptions/> to managing the list of subscriptions of a
mailinglist in mailman. It is very nice to be able to add/remove
subscribers in bulk or manage other aspects, but probably not critical.

The schema has minOccurs='0' for create, which should be '1' since we
moved the sole configure to the owner namespace. Also, I'm not sure
how to do that in the schema, but does it convey that you can't mix for
example <items/> and <unsubscribe/> in one request?

-- 
Groetjes,

ralphm



More information about the Standards mailing list