2195 introduced reverseLocate() and followLocatorNameChanges() to the directory. The implementation of the latter is incomplete, in that the subscriptions it creates can never be cancelled. This is unacceptable, and we have two options for solving this problem. We need more data before determining which path to pursue.
Option 1: Add cancellation
Subscribers must be furnished with the means to cancel their subscriptions. This can be done by exposing the ability to cause the async iterator that implements the subscription to return. In addition, once we have garbage collection, garbage collecting a locator should cancel any subscriptions for that locator.
Option 2: Punt this concern to the client layer
@kriskowal had the insight that followNameChanges() together with reverseLocate() furnishes the client with the capability to subscribe to the names of named locators. If the client encounters an unnamed locator, it will still be notified whenever such a locator is named. This "light client" approach may be sufficient for user interfaces, which is the purpose of followLocatorNameChanges(). It would also reduce the scope of garbage collection. This would require the implementation of a standalone module that would be imported by the client. The existing implementation could be repurposed to accomplish this.
2195 introduced
reverseLocate()andfollowLocatorNameChanges()to the directory. The implementation of the latter is incomplete, in that the subscriptions it creates can never be cancelled. This is unacceptable, and we have two options for solving this problem. We need more data before determining which path to pursue.Option 1: Add cancellation
Subscribers must be furnished with the means to cancel their subscriptions. This can be done by exposing the ability to cause the async iterator that implements the subscription to return. In addition, once we have garbage collection, garbage collecting a locator should cancel any subscriptions for that locator.
Option 2: Punt this concern to the client layer
@kriskowal had the insight that
followNameChanges()together withreverseLocate()furnishes the client with the capability to subscribe to the names of named locators. If the client encounters an unnamed locator, it will still be notified whenever such a locator is named. This "light client" approach may be sufficient for user interfaces, which is the purpose offollowLocatorNameChanges(). It would also reduce the scope of garbage collection. This would require the implementation of a standalone module that would be imported by the client. The existing implementation could be repurposed to accomplish this.