[standards-jig] JEP-0060 PubSub: 6.2.4 Modifying entity affiliations Example 66

Bob Wyman bob at wyman.us
Sun Feb 16 01:55:37 UTC 2003


    1) Example 66 shows that the server's response to a request for
current affiliations returns a list including a number of entity items
that have an affiliation of "none". If I understand things correctly,
then an affiliation of none appears to be semantically equivalent to
having no affiliation recorded in the system. Thus, I confused as to why
any entry would every have an explicit affiliation of "none." It seems
to me that setting an affiliation to none, since it is the equivalent of
deleting the entry, should actually result in the entry being deleted.
Is there some utility in carrying records which explicitly record
affiliation as "none"?
    If there is some utility in having an explicit affiliation of "none"
then I am left wondering "How does one delete an entry in this list?"
Given that a node may exist for a long time, even many years, if there
is no mechanism to delete entries, it seems like the list would grow
continuously as once active affiliations convert to "none" and become
inactive. If there is another mechanism for deleting entries in the
table, I encourage the author to provide an example of how it is done.

    2) If an affiliation is changed, is a message sent to the entity
that is the subject of the change? If I am made a "Publisher" how do I
discover that this has happened? It seem to me that such messages should
be sent. This would, at least, provide symmetry with the messages that
are sent when I become a subscriber or when a node is deleted. i.e. the
system should proactively inform me of changes that modify my
relationship with the system.

    3) Touching again the issue of "Is 'Subscriber' an affiliation?"
that has been discussed in other messages, I must say that I don't see
in the current draft any mechanism by which an administrator can
determine who is currently subscribed to a node. One mechanism for doing
this would be to include subscribers in the list of affiliations
returned in response to a request for affiliated entities. It should be
noted, however, that the list of subscribers could, in some cases, be
very large and it might be cumbersome to have to get a list of thousands
of subscribers every time you wanted to find out who the four or five
owners and publishers were... Thus, it might make sense to provide
distinct requests for retrieving lists of each type of affiliated
entity. Something like the following:

To discover who was an owner:
<iq type="get" from="pgm at jabber.org" to="pubsub.jabber.org" id="ent1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <entities node="generic/pgm-mp3-player"
              affiliation="owner" />
  </pubsub>
</iq>

To discover who was a subscriber:
<iq type="get" from="pgm at jabber.org" to="pubsub.jabber.org" id="ent1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <entities node="generic/pgm-mp3-player"
              affiliation="subscriber" />
  </pubsub>
</iq>


		bob wyman




More information about the Standards mailing list