[Nfd-dev] repo-ng protocol: ChildSelector

[Alex Afanasyev]

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/20140715/74f74653/attachment.html>