[Ndn-interest] any comments on naming convention?

Felix Rabe felix at rabe.io
Mon Sep 15 14:17:29 PDT 2014


I agree with a need for simplicity.

But maybe we cannot have simplicity so let's look at some use cases that 
might justify the complexity of the conventions: (I will only discuss 
versions and timestamps here, as they interest me for my work.)

Versions: I can give someone a link to a document, and know that they 
will see the version I currently see, unmodified, even if there is a 
newer version. Of course, any participant can always get a newer version.
- But: I think applications should come up with conventions in 
versioning, as one application does not need it, another needs 
sequential versioning, another (like Git-style source code management) 
needs a DAG.

Timestamps: My measurements are a growing data set of (time, value) 
tuples. I can access multiple measurements across time for comparisons.
- But: Also, this needs to be defined by applications, as 
time-since-unix-epoch is (I think) unsuitable for a wide range of 
applications (archaeology, astronomy), where both range and granularity 
requirements are different. Then, there is vector clocks which work with 
logical time instead of real time.
- Another aspect is that this could just be a special case of 
versioning, using time as a version "number".

Segments: ...
Sequence: ...

Just some thoughts
- Felix

On 15/Sep/14 22:05, Abdelzaher, Tarek wrote:
> Ok, here is a short perspective from a person who does not write 
> network code, but rather builds distributed applications:
>
> I feel squeamish about specifying naming conventions at all. I feel 
> that the design should favor simplicity and should not burden 
> application developers with having to understand what's better for the 
> network. Hence, I would argue in favor of names that are just series 
> of bits organized into substrings whose semantics are up to the 
> application. I would not use any special bits/characters or other 
> special conventions. I would also most definitely not embed any 
> assumptions on name conventions into network-layer code.
>
> As an application developer, I would like to be able to think about 
> name spaces the way I think of UNIX file-name hierarchies. To put it 
> differently, I do not want to read a tutorial on UNIX filename design 
> guidelines in order to ensure that the UNIX file system does file 
> caching, block management, and other functions efficiently for my 
> application. I want file system plumbing to be hidden from me, the 
> application developer. A good design is one that hides such plumbing 
> from the application without impacting efficiency. Same applies to NDN 
> in my opinion. A discussion of special delimiters, markers, etc, that 
> enhances efficiency of certain network functions seems to be going in 
> the opposite direction from what makes NDN general and flexible.
>
> Tarek
>
>
> On 9/14/2014 10:39 PM, Tai-Lin Chu wrote:
>> hi,
>> Just some questions to know how people feel about it.
>> 1. Do you like it or not? why?
>> 2. Does it fit the need of your application?
>> 3. What might be some possible changes (or even a big redesign) if you
>> are asked to purpose a naming convention?
>> 4. some other thoughts
>>
>> Feel free to answer any of the questions.
>> Thanks
>>
>>
>> [1] 
>> http://named-data.net/wp-content/uploads/2014/08/ndn-tr-22-ndn-memo-naming-conventions.pdf
>> _______________________________________________
>> 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




More information about the Ndn-interest mailing list