[standards-jig] JEP-0060 PubSub: What are my subscriptions?

Bob Wyman bob at wyman.us
Sun Feb 16 18:25:25 UTC 2003

    There should be a mechanism by which someone can determine what
subscriptions they have outstanding on a particular PubSub server. The
current draft (0.7) seems to provide no such mechanism. Hopefully,
future drafts will.
    1) It is likely that PubSub clients will present lists of current
subscriptions to users both for informational purposes as well as in
order facilitate the organization of messages that are published. From
time to time, due to crashes on users' machines, software
reconfiguration, etc. it is inevitable that the client-maintained lists
will not accurately reflect what the server believes is the current list
of subscriptions. Thus, it would be good to provide a means by which a
client can refresh or verify its list of subscriptions to ensure that it
is identical to that on the server.
    2) It is inevitable that people will want to use more than one
device to receive PubSub alerts and notifications. (for instance, a
desktop and a PDA). In such situations it is important that both the
device that creates a subscription and a later, different device that
may receive a notification, agree on what subscriptions exist. One could
build protocols to allow the two devices to synchronize, however, a much
simpler solution would be to allow clients to query the PubSub server to
discover what outstanding subscriptions exist.
    3) The PubSub protocol, as currently specified, seems to assume that
subscriptions are permanent. i.e. subscriptions have no "duration"
attribute or other attribute that can cause them to be canceled or
deleted after some period or upon some condition. Thus, it is likely
that many "dead" subscriptions will accumulate over time and consume
server resources unnecessarily. In such a situation, it would be good to
provide users with the information they need to "cleanup" unused or
undesired subscriptions whenever possible. However, in the case where
someone's client "forgets" what subscriptions are active, the only way
for a client to rediscover subscriptions is to learn from receiving a
published message. This "learning" is inadequate, however, since some
nodes will have relatively low traffic and it could be hours, weeks, or
months, between messages resulting from particular subscriptions. Thus,
it is likely that learning can't be relied on as a method for people to
reconstitute lost subscription lists. Thus, a mechanism should be
provided to let them discover their subscriptions.
    4) The ability to retrieve a list of active subscriptions is
analogous to the ability to retrieve a "roster" in XMPP or other
presence protocols. Given that presence protocols are nothing more than
a minimal subset of the PubSub problem, I believe that the fact that a
capability has been found useful in a presence system should be a strong
indicator that it should be provided in a more general PubSub
capability. (In fact, I'm constantly wondering why we bother having a
distinct presence protocol anyway...) Whatever, all the arguments that
led to providing the ability to retrieve rosters in presence also apply
to PubSub.

        bob wyman

More information about the Standards mailing list