Feature #2272
closed
Strategy API: access to FaceTable
100%
Description
Allow strategies to access FaceTable, including:
- enumerate Faces that satisfy a certain predicate
- subscribe to onAdd and onRemove events
Updated by Junxiao Shi almost 10 years ago
- Blocks Feature #1999: Strategy for access router added
Updated by Junxiao Shi almost 10 years ago
- Status changed from New to In Progress
Updated by Junxiao Shi almost 10 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
Updated by Alex Afanasyev almost 10 years ago
I don't understand why strategy needs to fire events for "create" and "remove" faces. I can understand that strategy may get notification about those events, but not invoke them. Strategy is not supposed to create faces and even if it creates, there should be separate non-strategy related interface for that.
Updated by Junxiao Shi almost 10 years ago
- Description updated (diff)
Strategies can subscribe to onAdd and onRemove events, which means they can get notifications.
The semantics of EventEmitter is that only the class in which EventEmitter is declared should trigger the event, and other classes can only subscribe to the event.
This rule is currently a convention; it cannot be enforced in code without changing declaration format.
This problem has nothing to do with #2272.
Updated by Junxiao Shi almost 10 years ago
- Blocked by Feature #2279: Signal: allow only owner to emit events added
Updated by Junxiao Shi almost 10 years ago
- Status changed from Code review to In Progress
Newly-introduced ndn::util::signal::Signal provides a way to prevent Strategy from raising FaceTable events.
Thus, I'm injecting a commit to convert FaceTable to use Signal: http://gerrit.named-data.net/1548
Updated by Junxiao Shi almost 10 years ago
- Status changed from In Progress to Closed