<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 class="h5"><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 class="h5"><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">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>