In structured extensions, I'm concerned that there may be an oversight in the design. AFAIK, there was no thought about nested custom parameters outside of the extension point. Currently, at least for my code, the body of the extension can only be comprised of core subparameter types and fields. Of course at the nested extension points you can put any extension.
The problem is with the current setup is there is no way to model "you need all of these things, exactly one of this set of things, one or more of this kind of thing, etc." when the "things" are *custom* subparameters. There is a lot more structural enforcement possibility available to the core than there is in our extension design. Keep in mind that from the LLRP spec perspective, custom parameters are just byte strings with no inherent semantics or structure. So we are free to put whatever structure we want on the extensions. Only being able to structure our extensions by nesting custom parameters at the unordered extension points seems like an unnecessary limitation on the extension designer, and (wastefully) doesn't allow the extension designer to leverage the error checking facilities you get when dealing with core parameters and messages. Thoughts? -- http://devwrights.com/blog ------------------------------------------------------------------------- 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
