I just wanted to get back to the list regarding the previous feedback from Paul, John, and Gordon on the Java design we proposed. Some of this was already mentioned in Prasith's mail on Monday.
> PFD Comment #1: The LLRPDevice holds and manipulates the > socket connection. I see three potential issues with this. ... Qouting from Prasith's email: We agreed that the toolkit would strictly be a message api which means that for now we will not have a connection or device communication profile. The role of the api is to provide a well designed java library for generating and understanding bit level LLRP messages. However, the design will be open enough to allow contribution of this module as readers start hitting the market anyone can contribute several different interfaces and make the toolkit more robust. > PFD Comment #2: Serialization, encode, decode, marshalling or > whatever one calls it. > > Perhaps this is a religious debate--brace yourself. In this > architecture, there will be at least two ways to > serialize/de-serialize these objects, LLRP binary and XML. > Whether there evolve any others via standard or convention, I > can't say, but the debate is this. Does the Parameter and > message objects contain serialization routines for each of > these methods (e.g. encode/decodeToLLRPBinary > encode/decodeToXML) or are there other classes (e.g. > LLRPBinaryEncoder) that know how to serialize objects from > the LLRPMessage class. I think it comes down to this. Are > the Java objects representations of the LLRP abstract? If > yes (which is my belief and preference), perhaps the binary > and XML serializations should live in a separate classes > keeping the abstract objects clean. > Again qouting from Prasith's email: After some discussion we favor the approach of having each message class have an individual encode/decode message as opposed to one monolithic encoder/decoder class. We felt that this was better for modularity, understandability and also works better with our code generation approach where we can lay out structures for each of the encode/decode operations for a class. Gordon's comment #1: > How does the decode of optional parameters work? > From the diagrams, it looks like an optional parameter is instantiated > and the decode(bits) called. Even if decode() recognizes that the > optional parameter is omitted, what happens to the instance? The generated code uses a simple if-else construct to determine whether the parameter is omitted or not. This is realised by looking ahead on the next parameter to decode. If the parameter is omitted in the message, the parameter is not instantiated (remains null). Gordon's comment #2: > Consider abstracting encode/decode. Think about translating between > objects and DOM trees, or maybe a pretty-printer instead of an XML > printer. > Not sure I understand. Gordon's comment #3: > How are enumerated values printed as symbols in the XML? We were going to use the enumerations specified in LLRP.xsd. Not sure whether this is what your question was really about. Gordon's comment #4: > How would custom parameters be done? I assume you refer to custom parameters as specified in Paul's LTK structured extension document. We are currently planning on reading in the "acmeExtensionDef.xml" together with the llrpdef.xml, validate it against llrpdef.xsd, and then have the appropriate statement in our Java class template (code generator) that make sure that the custom parameter class is generated just like any other LLRP parameter class and that the parameter is added to the message specified by the "allowed-in" tag. Gordon's comment #5: > I like the way y'all approached choice parameters. > Would this "interface" trick work if a parameter is a member of > multiple choices? yes, java allows for multiple inheritance. John's comment #1: >What's your take on enumerations for Integer subtype fields? Strongly typed I guess? Yes. John's comment #2: > I didn't notice anything here about the abstract XML format. Do you intend to > serialize/deserialize to the LLRP.xsd format? Yes. We just hadn't included this yet in the class diagrams. The class design is based on llrpdef.xml and we assume that LLRP.xsd is consistent with llrpdef.xml. John's comment #3: > Do you use lists for all sets of subparameters are will you allow strongly typed references to > individual subparameter objects? Not sure I understand this question. John's comment #4: > I see that you are attempting to make strongly, statically typed alternation (choice) points. Are > you considering strongly, statically typed extension points (Custom) as well? Yes. John's comment #5: > Note that strong typing precludes modelling non-conforming messages. > This is something that I permit in LTKPerl if you set a "Force" option when calling encode/decode. > This permits negative testing, and is one reason I recommend the Perl stuff for testing purposes. > Such a limitation on the Java toolkit is probably reasonable since its primary use will not be for > testing. There are probably some hooks you could add to allow this if you thought LTKJava were > going to be used broadly for testing. Maybe permit adding callback routines in the marshaller, > which could override portions of the message at the binary level while the framework would > recompute any Length fields as necessary. We were not planning on allowing for the testing you mentioned above. We would be quite happy to stick to our current design based on strong typing and rely on another implementation to facilitate this kind of testing. ------------------------------------------------------------------------- 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
