[Nfd-dev] repo-ng protocol: ChildSelector

[Shuo Chen]

OK, I will revise that in redmine

--
Shuo Chen


On Wed, Jul 16, 2014 at 1:10 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

> Hi Shuo,
>
> We talked today with Junxiao, Beichuan, Steve, and Lixia and I got
> convinced that ChildSelector is a special case.  While it makes a huge
> sense for Data retrieval, especially for discovery purposes, it has not a
> clear meaning for the deletion purposes.  When deleting, one better knows
> exactly what is being deleted (all data under prefix, all data that satisfy
> min/max suffix components within prefix, all data that satisfies exclude
> filter).   If we implement deletion of one Data packet when processing
> child selector, it could have nondeterministic behavior (which exactly
> "rightmost" data is deleted?).   Another angle to this is that multiple
> repeated deletion commands with the same selector should leave repo in the
> same state.  This is true for all selectors, except ChildSelector.
>
> The conclusion that we made and I hope you can agree with :) is that we
> should remove ChildSelector in the repo deletion spec.  This would simplify
> implementation and eliminate some confusions.
>
> --
> Alex
>
>
> On Jul 15, 2014, at 8:41 PM, Shuo Chen <chenatu2006 at gmail.com> wrote:
>
> The original design is like this:
> Selector match for delete Interest is to delete all Data packet that match
> selects. If you suppose delete one data, childselector should be added.
> If delete command just contains names without any selector, repo will
> delete all the data under this prefix.
>
> ----
> Shuo Chen
>
>
>
> On Wed, Jul 16, 2014 at 6:35 AM, Alex Afanasyev <
> alexander.afanasyev at ucla.edu> wrote:
>
>> My opinion is that semantics of delete operation in repo is different
>> from semantics of search operation (given that only one packet can be
>> returned).   When deleting, you suppose to already know what you're
>> deleting and if you specify prefix (or prefix with child selector, which in
>> turn also defines some prefix), then the whole subtree of this prefix
>> should be deleted.
>>
>> So, I'm voting for the following repo semantics:
>>
>> - selector match in normal Interest is to retrieve any Data that matches
>> selectors
>> - selector match for delete Interest is to delete all Data packet that
>> matche selects
>>
>> ---
>> Alex
>>
>> On Jul 15, 2014, at 12:02 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>> Dear folks
>>
>> I have difficulty understanding how repo-ng is expected to process
>> ChildSelector in the delete command.
>>
>> Repo protocol <
>> http://redmine.named-data.net/projects/repo-ng/wiki/Repo_Protocol_Specification#Repo-Command-Selectors>
>> states:
>>
>>    -
>>    - The concrete definitions of both standard NDN selectors and repo
>>    command selectors are the same.
>>    - the standard NDN selectors just matches one data packet that
>>    conforms to the selector conditions, but repo command selectors would
>>    matches any data packets.
>>    - Repo command supports parts of standard NDN interests including
>>    MinSuffixComponents, MaxSuffixComponents, PublisherPublicKeyLocator,
>>    Exclude, ChildSelector.
>>    - selectors are just supported in delete command.
>>
>> NDN-TLV spec <
>> http://named-data.net/doc/ndn-tlv/interest.html#childselector> states:
>>
>>    - Often a given Interest can match more than one Data within a given
>>    content store. The ChildSelector provides a way of expressing a preference
>>    for which of these should be returned.
>>
>> As I understand from these rules, an implementation is required to
>> process Selectors in a delete command, which is used as a filter to
>> determine whether a stored Data under the name prefix should be erased or
>> not.
>> However, ChildSelector is different from other selectors in that it does
>> not provide a filter, but expresses a preference about which one Data
>> should be picked among multiple equally-admissible Data.
>>
>> My question is: if ChildSelector is present in a delete command, should a
>> repo implementation evaluate the preference rules and erase only one Data,
>> or should this field be ignored?
>>
>> Yours, Junxiao
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140716/f78f76f9/attachment.html>