[Ndn-interest] any comments on naming convention?

[Felix Rabe]

To clarify: I agree with you. The "But" sentences are my arguments 
against conventions at NDN level for versions and timestamps.

On 16/Sep/14 01:07, Abdelzaher, Tarek wrote:
> Felix,
> At the risk of spamming the list, let me elaborate. What I am arguing 
> for is that we do not need unified conventions. Different applications 
> will find solutions that are more appropriate to them. Otherwise, 
> there will be too many things to add and it is a slippery slope. 
> Assume all we have are name strings composed of a concatenation of 
> sub-strings that, as far as the network is concerned, are all of the 
> same type (i.e., no special characters, markers, delimiters, type 
> values, etc), although from the application's perspective can have 
> different semantics.
>
> Hence, for example, if versions are important to my application, I 
> should have version numbers as part of the name space (e.g., 
> /path/data-name/version). To get a specific version, one can ask for 
> it by name (e.g., /path/data-name/version-label). To get the latest, 
> there is an issue with caching (how long should things be cached 
> before they expire). Barring that, one can ask for /path/data-name and 
> have the interest be forwarded to the provider assuming that stale 
> versions expired from caches. Alternatively, to make sure one bypasses 
> caching, one can have a "no cache" bit in the interest or ask for, 
> say, 
> /path/data-name/random-unique-substring-encoding-a-request-to-the-app. 
> Since the random-unique-substring-encoding-a-request-to-the-app will 
> not match any cached names, the interest will be sent to the provider 
> advertising the prefix, forwarded up to the application (registered on 
> the face exporting the prefix) and invoke an application-layer 
> function that will decode and interpret the 
> unique-substring-encoding-a-request-to-the-app. The function will then 
> answer the request by returning, say, the name of the requested latest 
> version to the client, so it can send a proper interest for the named 
> version. I am not suggesting that the above is necessarily a good 
> idea. I am just saying there can be many different ways to solve the 
> problem that depend on things such as how frequently versions are 
> updated, how big the objects are, etc. Hence, I am arguing for 
> simplicity and generality by making the underlying support as simple 
> as possible. Philosophically speaking, the more "common cases" we 
> think of and the more complex we make the underlying name format, the 
> more assumptions we may be making that time may break later, causing 
> the work to be potentially more short-lived.
>
> Tarek
>
>
> On 9/15/2014 4:17 PM, Felix Rabe wrote:
>> 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
>>
>