At issue is the definition of "End of AccessSpec" as an AccessReportTrigger. There are two possible interpretations that I can see, either the end of a single execution of the AccessSpec, or when the AccessSpec is deleted. The LLRP Specification does not explicitly define which of these definitions is correct, but my interpretation aligns with Gordon's, that the trigger means to send the results of each execution of the AccessSpec (similar to a ROSpec trigger with N=1). This seems to align best with other reporting trigger types.
Looking at the other possible definition, things get a little weird. If you wait until the AccessSpec completes, what if there is no bound to the AccessSpec execution? Even better, what if the ROSpec that has triggered the AccessSpec completes? Does the Reader hold on to the AccessSpec results but report the ROSpec results? Is an AccessSpec disable the same as a delete? I think the LLRP Specification could have better defined this report trigger, but I believe the intent of the Spec is to report on each AccessSpec execution. Thanks, C -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Waidhofer Sent: Tuesday, October 16, 2007 10:11 PM To: LLRP Toolkit Development List Subject: Re: [ltk-d] Access Reports The AccessSpec result should be attached to the TagReportData that was generated at the time the tag was under control of the reader. Such TagReportData can be delivered immediately (end of AccessSpec) or when the RO_ACCESS_REPORT is delivered. The count in the AccessSpec has nothing to do with reporting. It is how many times the AccessSpec is executed before it is automatically deleted. If the count is 10 and reporting is immediate, you can expected 10 RO_ACCESS_REPORTs each with a single TagReportData containing the AccessSpec result. I hope this helps. Regards, -gww -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kyle Sent: Tuesday, October 16, 2007 9:03 PM To: LLRP Toolkit Development List Subject: [ltk-d] Access Reports I am having a bit of trouble understanding the relationship between an accessreport and a roreport. From what I understand, each tag seen as a result of an AISpec generates a tagReportData. Then, a roreport (which is a collection of tagReportData params) can be sent at one of several times (at the end of an AISpec, at the end of a ROSpec, or after N tags have been seen). What I don't understand is how access operations affect this. If an access operation is performed on a tag, should the results of it go on the same tagReportData parameter that was generated because of the AI? The LLRP Spec seems to indicate so: "If there was an access operation performed on the tag, the results of the OpSpecs are mandatory in the report." However, accessreports can be set to send either after N accessspecs have been executed or after the rospec is done that the access specs were contained in. This seems to conflict with the access spec results being a part of the tagReportData generated by the aispec. For example, suppose the reader can see one tag. Suppose RoReports are set to send after every AISpec. Suppose that accessReports are set to be sent after every 1 accessSpec is executed. The reader executes the aispec and an access spec operation on the tag. Should one report be sent out, or two? If just one, should it be sent out after the access operation or after the AI? Thanks, Kyle ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
