[Ndn-interest] any comments on naming convention?

[Marc.Mosko at parc.com]

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

On Sep 17, 2014, at 3:02 AM, Massimo Gallo <massimo.gallo at alcatel-lucent.com> wrote:

> The why is simple:
> 
> You use a lot of "generic component type" and very few "specific component type". You are imposing types for every component in order to handle few exceptions (segmentation, etc..). You create a rule (specify the component's type ) to handle exceptions!
> 
> I would prefer not to have typed components. Instead I would prefer to have the name as simple sequence bytes with a field separator. Then, outside the name, if you have some components that could be used at network layer (e.g. a TLV field), you simply need something that indicates which is the offset allowing you to retrieve the version, segment, etc in the name...
> 
> 
> Max
> 
> 
> 
> 
> 
> On 16/09/2014 20:33, Mark Stapp wrote:
>> 
>> 
>> On 9/16/14 10:29 AM, Massimo Gallo wrote:
>>> 
>>> I think we agree on the small number of "component types".
>>> However, if you have a small number of types, you will end up with names
>>> containing many generic components types and few specific components
>>> types. Due to the fact that the component type specification is an
>>> exception in the name, I would prefer something that specify component's
>>> type only when needed (something like UTF8 conventions but that
>>> applications MUST use).
>>> 
>> 
>> so ... I can't quite follow that. the thread has had some explanation about why the UTF8 requirement has problems (with aliasing, e.g.) and there's been email trying to explain that applications don't have to use types if they don't need to. your email sounds like "I prefer the UTF8 convention", but it doesn't say why you have that preference in the face of the points about the problems. can you say why it is that you express a preference for the "convention" with problems ?
>> 
>> Thanks,
>> Mark
>> 
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- 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/242def90/attachment.bin>