[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