[Standards-JIG] pubsub tracking proto-JEP

Bob Wyman bob at wyman.us
Mon Feb 6 23:09:18 UTC 2006

Kevin Smith wrote:
> you need to query every server on which you are subscribed to nodes. So
> then you try and work out what servers you have subscriptions on 
> and...bang! you need a tracking method
	Ok. I misread the proto-JEP. All he's talking about here is a
mechanism for storing information about current subscriptions on some remote
system. This isn't "Tracking" -- it's storage. To me, the word "tracking"
implies some sort of active process.
	I would suggest that this process of storing subscriptions remotely
should NOT be considered "best-practice." The only authoritative source of
information on what subscriptions are active should be the servers that
support those subscriptions. Clients that try to persist that information
are likely to discover that all sorts of changes to the real world happen
that are not reflected in their stored data.
	We have this problem all the time in PubSub's JEP-0060
implementation. The problem is that users can have any number of clients
running and any of those clients can modify the subscriptions. Thus, a
client must always query for its subscriptions when it starts up and must be
prepared to query affiliation data on the fly when it receives a message
from a subscription that it doesn't know about. Any client side storage of
subscription meta-data should be volatile. 
	What would make sense is for a client to keep a list of the servers
that it believes holds subscriptions for it. Then, on start up it might
query those servers to see what they have. The client shouldn't trust any
potentially stale data concerning outstanding subscriptions.
	What doesn't seem to be handled at present is a mechanism by which a
Client-A can discover subscriptions made by a Client-B on a node not
previously known to Client-A and which does not result in a message being
delivered to Client-A. 

	bob wyman

More information about the Standards mailing list