> 3) There has been some concern over the limit of 255 custom extension > message per PEN. We don't forsee this as a problem in the short term, but > want to leave space for LTK structured extensions beyond 255. We'd like to > have the LTK reserve subtype 255 for future extensions. This would mean that > libraries would have to error-out when producing code for any custom > extension that tries to use the 255 subtype. >
To clarify, you wouldn't error out when serializing or deserializing any messages. If LTK doesn't know how to decode a Custom, it will generate a Custom Message or Custom parameter with a hex BLOB. The error-out would occur while processing a *def.xml file. For Perl, this is processed in order to build a data structure in memory. For all other current LTK implementations, this is during code generation phase. Because of this, this restriction wouldn't affect any extension authors not conforming to LTK Structured Extension format, since there is not likely to be a *def.xml file that would describe their extensions anyway. -- John. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
