<div dir="ltr">OK, I will revise that in redmine<div><br></div><div>--</div><div>Shuo Chen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 16, 2014 at 1:10 PM, Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi Shuo,</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>
<br></div><div>--</div><div>Alex</div><div><div class="h5"><div><br></div><br><div><div>On Jul 15, 2014, at 8:41 PM, Shuo Chen <<a href="mailto:chenatu2006@gmail.com" target="_blank">chenatu2006@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">The original design is like this:<div><span style="font-family:arial,sans-serif;font-size:13px">Selector match for delete Interest is to delete all Data packet that match selects. </span><span style="font-family:arial,sans-serif;font-size:13px">If you suppose delete one data, childselector should be added.</span></div>

<div><span style="font-family:arial,sans-serif;font-size:13px">If delete command just contains names without any selector, repo will delete all the data under this prefix.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>

</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">----</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Shuo Chen</span></div><div><br></div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Wed, Jul 16, 2014 at 6:35 AM, Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><div>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.</div>

<div><br></div><div>So, I'm voting for the following repo semantics:</div><div><br></div><div>- selector match in normal Interest is to retrieve any Data that matches selectors</div><div>- selector match for delete Interest is to delete all Data packet that matche selects</div>

<div><br></div><div>---</div><div>Alex</div><br><div><div><div><div>On Jul 15, 2014, at 12:02 AM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>> wrote:</div>

<br></div></div><blockquote type="cite"><div><div><div dir="ltr">Dear folks<div><br></div><div>I have difficulty understanding how repo-ng is expected to process ChildSelector in the delete command.</div><div><br>
</div><div>Repo protocol <<a href="http://redmine.named-data.net/projects/repo-ng/wiki/Repo_Protocol_Specification#Repo-Command-Selectors" target="_blank">http://redmine.named-data.net/projects/repo-ng/wiki/Repo_Protocol_Specification#Repo-Command-Selectors</a>> states:</div>



<div><ul><li></li><li>The concrete definitions of both standard NDN selectors and repo command selectors are the same.<br></li><li>the standard NDN selectors just matches one data packet that conforms to the selector conditions, but repo command selectors would matches any data packets.<br>



</li><li>Repo command supports parts of standard NDN interests including MinSuffixComponents, MaxSuffixComponents, PublisherPublicKeyLocator, Exclude, ChildSelector.</li><li>selectors are just supported in delete command.</li>



</ul></div><div>NDN-TLV spec <<a href="http://named-data.net/doc/ndn-tlv/interest.html#childselector" target="_blank">http://named-data.net/doc/ndn-tlv/interest.html#childselector</a>> states:</div><div><ul><li>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.<br>



</li></ul></div><div>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.<br>



</div><div>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.</div><div>



<br></div><div>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?</div><div><br></div><div>



Yours, Junxiao</div></div></div></div>
_______________________________________________<br>Nfd-dev mailing list<br><a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>

</blockquote></div><br></div><br>_______________________________________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div>