[Ndn-interest] any comments on naming convention?
felix at rabe.io
Tue Sep 16 00:34:59 PDT 2014
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:
> 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,
> 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.
> 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
>> - 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.
>>> On 9/14/2014 10:39 PM, Tai-Lin Chu wrote:
>>>> 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.
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.edu
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
More information about the Ndn-interest