[Ndn-interest] any comments on naming convention?

[Tai-Lin Chu]

1. Because we will never open up the entire tlv type space to
developers, markComponent is a must for application developers to add
custom types. we could make version and segment in tlv type space, but
since we will have markComponent anyway, placing them into
markComponent might be be a bad choice.

2. for comparison, it is fairly simple to address. It only masses up
sorting if we do direct strcmp. We parse both key and value. Compare
key first. If the keys are the same, compare value like normal name
component. Also markComponent is less than regular one. This means
that we define another sorting scheme for markComponent. I don't think
exclude will be an issue anymore.







On Wed, Sep 17, 2014 at 11:13 AM,  <Marc.Mosko at parc.com> wrote:
>
> If you want to keep exclusions, and to some extent left/right-most child, I
> think you only have a few options.  For example, how do I exclude a version
> component but not a binary component with the same bytes?  Are you going to
> add a MarkedComponent option to each exclusion predicate?
>
> 1) Use one “T” then always use a (key=value) pair in the name component of
> every name component.  This is a TLKV encoding.
> 2) Ditch TLV for name components, use a run-length encoding L(key=value)
> (LKV encoding), the exclude will include the “KV” as the “NameComponent”.
> 3) Use #2 with the observation that it’s really LTV encoding by another
> name.
> 4) Use one “T” and use the “_v/…” name component pairs.
> 5) Use MarkedComponents and extend the exclusion predicate to include the
> type.
> 6) Don’t use exclusions (the ccnx 1.0 option)
>
> It is not straightforward to include the type directly in the exclusion if
> you use multiple "T" TLV encoding with multiple types.  You’d need to change
> the grammar of the exclusion.
>
> Exclude ::= EXCLUDE-TYPE TLV-LENGTH Any? (NameComponent (Any)?)+
> Any ::= ANY-TYPE TLV-LENGTH(=0)
>
>
> Did I miss anything?
>
> Marc
>
> On Sep 17, 2014, at 10:10 AM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>
> 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>
> Date: Wednesday, September 17, 2014 7:46 AM
> To: "Marc.Mosko at parc.com" <Marc.Mosko at parc.com>
> Cc: "ndn-interest at lists.cs.ucla.edu" <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> 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
>>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>