NFD » ndn-cxx

This task will be rejected, as the applications WILL NOT do remote registrations.

This will be the job of NRD, which will automatically infer when to do localhop prefix registrations, based on the input from localhost registrations.

If not rejected, this task should be very specific. Controller should send localhop registrations only when face is associated with non-local transport.

I agree that regular applications SHOULD NOT perform remote prefix registration. However, this is not the basis of rejecting this Task.

This Task allows remote prefix registration commands to be generated and signed by Controller.
This feature is intended to be used by the process who is supposed to send remote prefix registration commands, and certain administrative and testing tools.
This feature, similar to FIB Management commands, is not intended to be used by regular applications.

Controller itself shouldn't forbid remote prefix registration commands to be sent to a local face.
Face::registerPrefix, the public API for regular applications, makes the choice of whether to send a local or remote prefix registration command.

20141024 conference call rejects the design in note-10.

Reason for this rejection is: If we allow application to change signing identity on the Controller owned by Face, prefix unregistration command may incorrectly use different signing identity than prefix registration command.

An alternate design is agreed:

interface Controller
{
  Controller(Face&);

  void start<Command>(CommandParameters, CommandSucceedCallback, CommandFailCallback, CommandOptions);
};

struct CommandOptions
{
  union {
    void useDefaultSigningIdentity;
    Name signingIdentity;
    IdentityCertificate signingCertificate;
  }; // either one of these three should be satisfied; implement shouldn't use 'union'

  time::milliseconds timeout;
  Name prefix;
};

Face::registerPrefix and similar methods should take optional CommandOptions, and don't need multiple overloads.

Controller no longer owns a KeyChain, but uses the KeyChain from Face.
Face constructor can take KeyChain:

Face(shared_ptr<Transport> transport, io_service& io, KeyChain& keyChain);

void useDefaultSigningIdentity => bool useDefaultSigningIdentity

void useDefaultSigningIdentity => bool useDefaultSigningIdentity

The union shown in note-11 is an abstract which indicates three properties are mutually exclusive.

The implementation is likely to have an enum to indicate which option is chosen, and two fields for identityName and certificate.

Callers can access those fields via getters/setters similar to those in note-10.

Change-Id: Iecc60c45ba6134dbcc34f58dcdf6a171e7b05253 gives Face class an internal KeyChain.

Upcoming commits:

• In Face::registerPrefix and similar methods, use CommandOptions
• Put DEPRECATED macros on all deprecated items in this Task, in order to warn library users

http://gerrit.named-data.net/1369 lets Face::registerPrefix use CommandOptions and no longer uses deprecated overloads of Controller::start.