Adds reverseLocate() and followLocatorNameChanges() to the daemon's directory. To match this new method, the directory's followChanges() and the pet store's underlying follow() are renamed to followNameChanges().
The directory's reverseLocate(locator) and followLocatorNameChanges(locator) are backed up by the pet store's reverseIdentify(id) and followIdNameChanges(id), respectively. The implementation of the former is very straightforward. The implementation of the latter required the introduction of a new pubsub topic, idChangesTopic, and a map from ids to idChangesTopic subscriptions (one for each id).
Since the pet store is unaware of whether ids exist, followIdNameChanges() will naively create a subscription that first publishes an empty array of names, and then any subsequent names that are added for that id. followLocatorNameChanges() inherits this property.
The current implementation suffers from the limitation that locator name change subscriptions cannot be ended. A follow-up will introduce the ability for subscribers to cancel their subscription. Locator subscriptions will also be a target for our future garbage collector, which will delete subscriptions for unreachable locators. Cancelling a locator should not end the subscription, because we consider the liveness of a value to be orthogonal to the subscriber's interest in changes to its names.
Adds
reverseLocate()andfollowLocatorNameChanges()to the daemon's directory. To match this new method, the directory'sfollowChanges()and the pet store's underlyingfollow()are renamed tofollowNameChanges().The directory's
reverseLocate(locator)andfollowLocatorNameChanges(locator)are backed up by the pet store'sreverseIdentify(id)andfollowIdNameChanges(id), respectively. The implementation of the former is very straightforward. The implementation of the latter required the introduction of a new pubsub topic,idChangesTopic, and a map from ids toidChangesTopicsubscriptions (one for each id).Since the pet store is unaware of whether ids exist,
followIdNameChanges()will naively create a subscription that first publishes an empty array of names, and then any subsequent names that are added for that id.followLocatorNameChanges()inherits this property.The current implementation suffers from the limitation that locator name change subscriptions cannot be ended. A follow-up will introduce the ability for subscribers to cancel their subscription. Locator subscriptions will also be a target for our future garbage collector, which will delete subscriptions for unreachable locators. Cancelling a locator should not end the subscription, because we consider the liveness of a value to be orthogonal to the subscriber's interest in changes to its names.