I have added clarifying changes and open issues to the LTK Structured Extensions wiki regarding:
a) Nesting Custom Parameters within Custom Messages and Custom Parameters *outside of the extension points* b) Some preliminary consideration of Structured Extension versioning http://llrp-toolkit.wiki.sourceforge.net/Structured+Extensions Both of these have aspects that are in-transition, non-final, but please take a look. If you are on this list, decisions made in this area will impact *you*. On the "versions" thing I'm hoping to spark a discussion on appropriate ways to version groups of extension messages and parameters. Core LLRP has a built-in facility for versioning the core, but at present little thought has been given to versioning extensions. It is certainly possible to decide this per-vendor and by carefully administering the PEN "namespace" among groups and products produced by an organization. However, I think serious consideration should be given to resolving this question in LTK. Why is this important? Suppose in your reader product or middleware you are collaborating on and want to adopt the nascent University of Mars "FooID" set of extensions. But, FooID comes in two immediately foreseeable variants, version 0.5 which is available now, and version 1.0, which is still being debated but available in two months. You aren't completely sure what 1.0 will be, so you want to declare compatibility with 0.5. At the LTK-XML level, the version will be apparent in the namespace URI. But what about the binary level? Other considerations arise: suppose 1.0 is supposed to be binary backwards compatible with 0.5, though no guarantees are being made. But you would like to be able to take advantage of that, and not "break" if 1.0 does turn out to be backwards compatible. At least you support a compatible subset. Is it possible to make that "just work?" Clever solutions that minimize development impact are ideal of course. My personal opinion is that we should reserve a binary "version" field in Structured Extension custom message and custom parameter headers just after the PEN and Subtype, similar to the Version field in LLRP Core messages. This would at least permit different versions to coexist in a way that is compatible with LTK-XML, since it would permit the Toolkit implementation to "lookup" the appropriate namespace URI based on the binary data. This wouldn't resolve any questions raised around "negotiation," but I'm not clear whether that is as serious of an issue. At least with a version number present, we lay the groundwork for dealing with these issues when/if it becomes a big problem. Sufficient "information" would be present to determine version even as the semantics of given versions are left for future consideration. Thanks, -- John. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
