[Ndn-interest] any comments on naming convention?

[Thompson, Jeff]

Hi Junxiao,

In your MarkedComponent proposal, would you want to make the marker code fixed-length to address the concerns explained by Marc?  In other words, the desire that a shorter name component value always sorts before a longer component value, regardless of its type?  (The risk is that a shorter component value may have a marker code which encodes as a long VAR-NUMBER which would make the overall TLV longer and mess up the sorting.)

- Jeff T

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Wednesday, September 17, 2014 7:46 AM
To: "Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>" <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>
Cc: "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>" <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>>
Subject: Re: [Ndn-interest] any comments on naming convention?

Hi Marc

The MarkedComponent proposal <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html> is precisely a T0/T1 system:

  *   T0=NameComponent
  *   T1=MarkedComponent
  *   key is encoded as variable length number (same way as T)

This still requires all codes to distinguish between NameComponent and MarkedComponent everywhere, but we'll have exactly two types, instead of potentially many types.

However, I agree that putting the key into TLV-TYPE is better than using MarkedComponent or having a key in every component, because the processing cost isn't any different.

Yours, Junxiao

On Wed, Sep 17, 2014 at 7:36 AM, <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> wrote:
I think if you require all name components to have a “key=value” format, then that is an ok system, but it seems duplicative of having the TLV type.   Personally, I would then encode the “key=“ piece the same way you encode the TLV “T” (i.e. the 1/3/5 system).

Though it does seem rather duplicative of having the TLV type, as I said.  I think having one T (call it T0) for non-tagged and one T (call it T1) for “key=value” introduces more overhead than is needed, as you now have two type systems for one value.  You will need to keep the T0/T1 distinction everywhere in the code so you know if there is a “key=“ embedded in the name.  Programmatically, you’ll probably need to sprout a new class or getter/setter for the “key=“ for those types.  It seems simpler to me for the TLV “T” to always be associated with a name component, so you are always working with the (T, value) pair.

Marc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140917/80c16dba/attachment.html>