Feature #2961
closed
Added by Tai-Lin Chu almost 9 years ago.
Updated over 6 years ago.
Description
Introduction¶
There are two parts in this proposal:
- Remove maxSuffixComponent, minSuffixComponent, and exclude
- Add "accept"
Accept¶
Accept deals with suffixes, which are names.
To make sure that we are on the same page, I give one example:
data name: /a/b/c
interest name: /a
suffix: /b/c (a name with 2 components)
Now I define "accept":
Accept ::= ACCEPT-TYPE TLV-LENGTH (Interval)+
Interval ::= INTERVAL-TYPE TLV-LENGTH (Name? Name?) // (Name .. Name)
Note:
- These intervals are open.
- None of them should overlap, so the form is canonical.
- An omitted left open interval is the smallest suffix; an omitted right open interval is the largest suffix. In a interval, the endpoints cannot both be omitted.
- Accept deals with the suffix space (not full name).
Accept offers "deep" cuts in the suffix space tree (each interval contains names instead of components). Moreover, it directly specifies the target X instead of excluding NOT X.
- Tracker changed from Task to Feature
- Subject changed from New selectors to Accept Selector
- Start date deleted (
06/24/2015)
Accpet Selector violates a fundamental principle: the question is in the Name, and Selectors are only used for Name discovery.
This is because a suffix contains multiple components. I don't think that it violates anything.
Before talking about any implementation details, you should show a use case for the proposal, what are major benefits, and what are the trade offs. Two parts of the proposal are completely orthogonal and require individual motivation and reasoning.
Accept example¶
/dataset/{start_timestamp}/{end_timestamp}
With this selector, we can also select on end timestamp. Accept is basically the negation of the exclude selector with more power (more than 1 component) to refine queries.
Reason to remove maxSuffixComponent, minSuffixComponent, and exclude¶
- Accept, which is a generalization of exclude, can replace exclude.
- min/maxSuffixComponent can select on "depth" in a suffix space tree. If one thinks that "accept" selects vertically, then these two selectors select horizontally. Therefore, accept + min/maxSuffixComponent gives an area in the suffix space tree; childselector then specifies the order preference within the area (mustbefresh and publisherkeylocator are not related to name tree exploration, and these are all the selectors that we have now). On one hand, min/maxSuffixComponent completes selectors; on the other hand, it does not select much semantically on its own.
/dataset/{start_timestamp}/{end_timestamp}
With this selector, we can also select on end timestamp.
This implies the consumer is asking a question in a Selector rather than in the Name, which violates the principle stated in note-1.
Although, I also wonder how a two-variable query can be done in NDN Name.
A different example is /map/{latitude}/{longitude}.
I may be wrong, but I don't think that it is possible.
A name tree is first explored statically with a name. Then you get a suffix tree, which can only be explored dynamically with selectors.
- Description updated (diff)
- Status changed from New to Abandoned
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by