I am partial to allowedIn because I believe
it makes code generation easier. I am studying
the alternative extendParameter directive.
When an extension is defined -- most likely
by a reader maker -- it seems where the extension
is allowed would be entirely known. If the
extension originator will support the extension
in additional places, why wouldn't they modify
their description? What good does it do that
a third party could amend the description?
An amended description does not suddenly make
the reader able to support the extension in the
new place, right? John, do you have a practical
example of how those degrees of freedom would
be used?
While I don't know the full impact of the
proposed change I am satisfied that it makes
code generation harder. I'd like to understand
how the greater effort is worth while.
Regards,
-gww
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of John R. Hogerhuis
Sent: Thu 9/20/2007 10:06 AM
To: LLRP Toolkit Development List
Cc:
Subject: [ltk-d] Proposed change to llrpdef.xml [heur]
In custom definitions, we restrict/extend core messages and parameter
extension points using the 'allowedIn.' I'm not a big fan of this...
it implies that we're saying something about the custom type being
defined when in fact we are extending a completely different type.
I think it is like this because there is no other obvious place to put
it if you leave the llrpdef.xml inviolate when adding vendor
extensions.
I think it would be easier to understand if the extension productions
were separated.
<customParameterDefinition name="AcmeExtA" vendor="Acme" subtype="50">
<field type="u16" name="ExtAField" enumeration="AcmeExtAEnum"/>
<parameter repeat="0-N" type="Custom"/>
<allowedIn name="GET_READER_CONFIG_RESPONSE"
type="GET_READER_CONFIG_RESPONSE" repeat="0-1"/>
<allowedIn name="SET_READER_CONFIG" type="SET_READER_CONFIG" repeat="0-1"/>
</customParameterDefinition>
becomes something like:
<customParameterDefinition name="AcmeExtA" vendor="Acme" subtype="50">
<field type="u16" name="ExtAField" enumeration="AcmeExtAEnum"/>
<extension-point/>
</customParameterDefinition>
<extendMessage type="GET_READER_CONFIG_RESPONSE">
<allow type="AcmeExtA" repeat="0-1"/>
</extendMessage>
<extendMessage type="SET_READER_CONFIG">
<allow type="AcmeExtA" repeat="0-1"/>
</extendMessage>
<extendParameter type="AcmeExtA" namespace="Acme">
<allow type="UnivFutureBlah" repeat="1-1"/>
</extendParameter>
Seems much cleaner to me. It is more like the xml schema approach, and
clearly they put a lot of thought into extensions. We might be
avoiding some problems that way.
For example, with this approach you could conceivably "allow" an
extension in an additional type without modifying the main Acme
extension file. With the existing approach, the "include" level
extensibility dead-ends at an extension file. If you want to extend an
extension, you have to modify the existing extension file.
So we have a bit of asymmetry here if we leave it as-is.
Plus it is a basic object oriented principle of coupling. allowedIn
more tightly couples a customParameter or customMessage definition to
core types. The custom types should be able to stand-alone until the
designer decides to make an association.
Any obvious problems with such a change? What is the impact to
existing code we can do anything about (in LTK repository or another
public repository)
-- 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
-------------------------------------------------------------------------
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
