NFD » ndn-cxx

I would like to add, that it would be useful if non-verified data packet was returned to users of the SegmentFetcher. In some scenarios (video streaming), users may opt to proceed to fetch non-verified data.

This is not really the callback issue. How to verify data and what to do if data cannot be verified should be part of what Validator is doing. If you don't want to validate (or have special logic for verification), then we can have special Validator that is supplied to SegmentFetcher.

Alex Afanasyev wrote:

This is not really the callback issue. How to verify data and what to do if data cannot be verified should be part of what Validator is doing. If you don't want to validate (or have special logic for verification), then we can have special Validator that is supplied to SegmentFetcher.

I'm having troubles picturing such a Validator. Will there be any callbacks in it and who's going to receive them - SegmentFetcher or the user who supplied this Validator to SegmentFetcher?

When you create SegmentFetcher, you supply an instance of the Validator. Inside the validator, there are set of callbacks to "verify" or "reject" data packet. There are many ways you can implement such a validator.

In my case, the user of Validator is the application (ndncon), while SegmentFetcher user is the library (ndn-rtc) this application was built with. Thus, receiving callback from Validator in the application for the data that was fetched within the library won't make sense. Or I'm missing something here...

It doesn't really matter what is implemented where. What is going to happen:

• ndncon-specific Validator instance m_validator
• instance of library's SegmentFetcher m_fetcher that gets m_validator as a constructor parameter

m_fetcher calls whatever it needs to retrieve data. After retrieval, it calls m_validator interface to verify data. m_validator either OK's or Fail's the data. If it fails, m_fetcher calls ErrorCallback from this issue. If it wants to allow "proceed", it will simply not call the ErrorCallback.

Then why special validator is needed here?

When m_fetcher proceeds upon validation error, it needs to supply fetched data to the library and somehow tell that the data is not verified. This information will be propagated to the application, but the data will be used by the library if it was configured to use non-verified data.