[Nfd-dev] nfdc implicit face creation problems
Alex Afanasyev
aa at CS.UCLA.EDU
Tue Jan 31 10:27:13 PST 2017
> On Jan 31, 2017, at 10:18 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
>
> Dear folks
>
> I do not support this proposal. This creates inter-commmand dependency for basic operations as registering prefix to a new face. We should not create more obstacles for users for the sake of having consistent interface with IP tools.
>
> Let's rewarm the original rationale of introducing implicit face creation: what we needed is not implicit face creation, but the ability to write FaceUri into nfdc register command in place of FaceId.
> Before #1515, nfdc register command only accepts FaceId. A caller must first invoke nfdc create, scrape its output (or nfd-status -f output), and then invoke nfdc register. This is the "inter-command dependency".
>
> At that time, there were no faces/query operation, so that the easiest way to obtain FaceId from FaceUri is to execute faces/create command. It has caused a long list of concerns in #1515 <https://redmine.named-data.net/issues/1515>.
> When faces/query operation was later introduced, some of the concerns are solved, but it's too late the change the semantics of nfdc register subcommand.
>
> Under the new proposal, nfdc route add command accepts FaceUri and uses that to query an existing face. This should not be considered "inter-command dependency", because the operator can simply run "nfdc face create udp://hobo.cs.arizona.edu <http://hobo.cs.arizona.edu/> && nfdc route add / udp://hobo.cs.arizona.edu <http://hobo.cs.arizona.edu/>" without scraping the output of the first subcommand.
I that case, I don't understand what the question/proposal is really about. Remove faceUri handling for unregister? unregister doesn't support faceUri (per man page) already.
--
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170131/5da214fd/attachment-0001.html>
More information about the Nfd-dev
mailing list