[Ndn-interest] any comments on naming convention?

[Felix Rabe]

On 16/Sep/14 19:21, Tai-Lin Chu wrote:
> Summarize all types that people need (feel free to add some, and paste
> in your reply)
> - regular
> - segment
Segment: As I think more of it, this seems just like versioned content 
with a known end (length), with continuous numbering from 0...length-1. 
Whereas "usual" versioned content has an open end, but a latest version 
(somewhere). (Of course, the difference is that versioned content is 
similar or related content in a sequence, whereas segments are parts of 
the whole data.)
> - version (timestamp)
> - signature
> - key: assuming that the next regular component will be value. The
> value is empty if it sees another key component immediately after.
Empty value: I would not allow this special case. You will soon find 
someone who tries to have an empty component, but for that needs to have 
some other (dummy) key just after that. Better to either allow empty 
components in general, or don't allow them here eiter.

> - app-specific
>
>
> However, I am not convinced that we need version, signature, and
> app-specific as typed component. Will these change how packet routes?
>
>
>
> On Tue, Sep 16, 2014 at 8:47 AM, Junxiao Shi
> <shijunxiao at email.arizona.edu> wrote:
>> Hi Jeff
>>
>> Please see my proposal of MarkedComponent
>> <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html>,
>> which is a solution to eliminate ambiguity by defining a new type
>> specifically for key-value pair.
>>
>> Yours, Junxiao
>>
>> On Tue, Sep 16, 2014 at 8:18 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>>>
>>> Second, if the most important issue is eliminating ambiguity/aliasing,
>>> then why not define a new type that hints that the component can be
>>> interpreted as a key/value pair with some encoding convention?  This could
>>> enable an unambiguous, short list of commonly used conventions that you've
>>> mentioned (using marker-like keys),  while keeping information describing
>>> the data object in the name. It would also be very useful for applications
>>> that desire their own k/v representation for components, which Dave has
>>> argued for in other circumstances and we keep running across. It doesn't
>>> rule out use of hierarchy, and doesn't limit what an application defined
>>> keys could be.  Yet, it could be ignored in forwarding (just another
>>> component) and perhaps have a still-meaningful sort order (key, then
>>> value).
>>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest