Feature #4438
closed
Add a signal to SegmentFetcher to notify the reception of a Data segment
100%
Description
Currently, there is no way to get the actual segmented data packet from segment fetcher.
The task involves doing the following:
(1) Add a ndn::util::Signal in the ndn::util::SegmentFetcher
(2) The SegmentFetcher::fetch() method will return the SegmentFetcher instance it creates.
Application can use the returned segment fetcher instance to connect to the signal.
Updated by Davide Pesavento almost 7 years ago
- Tracker changed from Task to Feature
- Subject changed from Add a signal in the segment fetcher to detect the receiving of a data segment. to Add a signal to SegmentFetcher to notify the reception of a Data segment
- Category set to Utils
- Target version set to v0.7
Updated by Muktadir Chowdhury almost 7 years ago
- Related to Feature #4448: Serve other routers' certificates added
Updated by Muktadir Chowdhury almost 7 years ago
- Related to deleted (Feature #4448: Serve other routers' certificates)
Updated by Muktadir Chowdhury almost 7 years ago
- Blocks Feature #4448: Serve other routers' certificates added
Updated by Junxiao Shi almost 7 years ago
For NLSR’s use case, I’d suggest an additional signal:
Signal<SegmentFetcher, Data> afterSegmentValidated;
This is emitted only if the Data passes validation.
Updated by Davide Pesavento almost 7 years ago
I'm not against using signals in general, but the current SegmentFetcher API is based on callbacks. This proposal mixes callbacks and signals, and makes the API ugly and inconsistent. Any reasons we're not augmenting the API by adding more callbacks? Or alternatively, why not make the whole API signal-based? (in the latter case, existing callbacks can be deprecated and eventually removed).
Updated by Davide Pesavento almost 7 years ago
- Status changed from In Progress to Code review
Updated by Junxiao Shi almost 7 years ago
Any reasons we're not augmenting the API by adding more callbacks?
There are already too many of them.
why not make the whole API signal-based?
I agree with this. In this case, fetch function shall be renamed as start and the function does not take any callbacks.
The fetch function becomes deprecated.
Updated by Muktadir Chowdhury almost 7 years ago
Junxiao Shi wrote:
Any reasons we're not augmenting the API by adding more callbacks?
There are already too many of them.
why not make the whole API signal-based?
I agree with this. In this case,
fetchfunction shall be renamed asstartand the function does not take any callbacks.
Thefetchfunction becomes deprecated.
I think it should be in a different commit. What do you think? I can crate an issue for this.
Updated by Alex Afanasyev almost 7 years ago
Guys, I don't disagree with moving to signal based, but I would consider it is "beautification" that we can do later in due time. We have kind of an emergency to make this specific signal work, so let's not stall.
Updated by Muktadir Chowdhury almost 7 years ago
Created an issue #4464 to make SegmentFetcher Signal based.
Updated by Davide Pesavento almost 7 years ago
- Status changed from Code review to Closed
- % Done changed from 0 to 100