Project

General

Profile

Feature #4438

Add a signal to SegmentFetcher to notify the reception of a Data segment

Added by Muktadir Chowdhury about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Category:
Utils
Target version:
Start date:
01/08/2018
Due date:
% Done:

100%

Estimated time:

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.


Related issues

Blocks NLSR - Feature #4448: Serve other routers' certificatesClosed2018-01-09

History

#1 Updated by Davide Pesavento about 1 year 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

#2 Updated by Muktadir Chowdhury about 1 year ago

  • Related to Feature #4448: Serve other routers' certificates added

#3 Updated by Muktadir Chowdhury about 1 year ago

  • Related to deleted (Feature #4448: Serve other routers' certificates)

#4 Updated by Muktadir Chowdhury about 1 year ago

#5 Updated by Junxiao Shi about 1 year 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.

#6 Updated by Davide Pesavento about 1 year 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).

#7 Updated by Davide Pesavento about 1 year ago

  • Status changed from In Progress to Code review

#8 Updated by Junxiao Shi about 1 year 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.

#9 Updated by Muktadir Chowdhury about 1 year 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, fetch function shall be renamed as start and the function does not take any callbacks.
The fetch function becomes deprecated.

I think it should be in a different commit. What do you think? I can crate an issue for this.

#10 Updated by Alex Afanasyev about 1 year 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.

#11 Updated by Muktadir Chowdhury about 1 year ago

Created an issue #4464 to make SegmentFetcher Signal based.

#12 Updated by Davide Pesavento about 1 year ago

  • Status changed from Code review to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF