[Ndn-interest] any comments on naming convention?

[Tai-Lin Chu]

> if you do not need the entire hierarchal structure (suppose you only want the first x components) you can directly have it using the offsets. With the Nested TLV structure you have to iteratively parse the first x-1 components. With the offset structure you cane directly access to the firs x components.

I don't get it. What you described only works if the "offset" is
encoded in fixed bytes. With varNum, you will still need to parse x-1
offsets to get to the x offset.



On Wed, Sep 17, 2014 at 11:57 PM, Massimo Gallo
<massimo.gallo at alcatel-lucent.com> wrote:
>
> On 17/09/2014 14:56, Mark Stapp wrote:
>>
>> ah, thanks - that's helpful. I thought you were saying "I like the
>> existing NDN UTF8 'convention'." I'm still not sure I understand what you
>> _do_ prefer, though. it sounds like you're describing an entirely different
>> scheme where the info that describes the name-components is ... someplace
>> other than _in_ the name-components. is that correct? when you say "field
>> separator", what do you mean (since that's not a "TL" from a TLV)?
>
> Correct.
> In particular, with our name encoding, a TLV indicates the name hierarchy
> with offsets in the name and other TLV(s) indicates the offset to use in
> order to retrieve special components.
> As for the field separator, it is something like "/". Aliasing is avoided as
> you do not rely on field separators to parse the name; you use the "offset
> TLV " to do that.
>
> So now, it may be an aesthetic question but:
>
> if you do not need the entire hierarchal structure (suppose you only want
> the first x components) you can directly have it using the offsets. With the
> Nested TLV structure you have to iteratively parse the first x-1 components.
> With the offset structure you cane directly access to the firs x components.
>
> Max
>
>
>>
>> -- Mark
>>
>> On 9/17/14 6:02 AM, Massimo Gallo 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