[Ndn-interest] any comments on naming convention?

[Marc.Mosko at parc.com]

Yes, I meant to be referring to the MarkedComponent proposal with my T0/T1 example, but I did not call it out specifically.

In the MarkedComponent proposal, the program state per name component is (hasKey, [key], value).  So, each name component becomes multi-modal (ok, bi-modal).  Some have a key some do not have a key.

In the “use the TLV type for markers” proposal (need a spiffier name for that, but it’s what ccnx 1.0 does), the program state is (T, value).  Not multi-modal.

Marc

On Sep 17, 2014, at 7:46 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> 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> 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/4777f466/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2595 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140917/4777f466/attachment.bin>