This is my comments on the general_structure.png. Other comments from me will trickle in over a few days.
PFD Comment #0: Thank you. This is excellent work, which done now will save lots of headaches later. Nice documentation and thoughts on the design. These comments may apply to other toolkit libraries as well. Perhaps other library authors could chime in on their design thoughts. PFD Comment #1: The LLRPDevice holds and manipulates the socket connection. I see three potential issues with this. 1) First, it's certainly possible that there will be LLRP implementations that are not socket based (USB or serial for example) but still use the binary representation. Although there is nothing in the standard, for this, it seems likely and I wouldn't want to break the compatibility of the main LLRPDevice class API if another interface was suggested. 2) 2nd, for usability, this library could build an LLRP reader or client. Both are allowed to initiate and terminate connections and each endpoint is allowed to have multiple connections following slightly different rules. This behavior may be complicated to provide in its entirety hidden within the LLRPDevice class. Decoupling socket behavior will allow people to customize that class for their own purposes while not having to change the LLRPDevice class. 3) The socket interface is heavily tied to the binary representation of LLRP. The LLRP device should be flexible to be expanded for another binding if necessary (e.g. serial). I'd suggest breaking the socket out of the LLRPDevice. How? Create an LLRPFrameClass. Alternately, you could just provide an LLRP stream interface, but I think that would be less flexible as other binary representations would likely have slightly different framing but use the same binary format. Also, this would allow people to bypass the decoder and do their own which may be handy for custom messages and also for performance issues with certain messages (e.g. low latency path GPI ). Second, create a generic stream interface for the LLRPFrame class so that it can be a socket, pipe, file, etc. Most of this comment would not affect the code generator as I suspect this is the hand-written code. 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. This would likely significantly impact a code generator as the generator would have to add "smarts" to encode and decode into other classes. If you combine these two comments (frame/socket and serialization classes), you may get a different picture at the general level. (An LLRPDevice holds a serialization Factory which can generate multiple serializer for LLRPBinary and LLRP XML.) How the LLRPFrame and LLRPListener hook together would require some thought. Regards Paul -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Lampe Sent: Wednesday, August 08, 2007 4:07 PM To: LLRP Toolkit Development List Cc: Basil Gasser; floerkem Subject: [ltk-d] Proposal for Java Impl based on llrpdef.xml Hi all, Please find attached three UML class diagrams that illustrate our proposal for a Java implementation that is based on llrpdef.xml. We are sending this to the mailing list because we would like to get some feedback on the design before we begin work on the code generator. The class structure shown in the diagrams only features the ADD_ROSPEC method and associated parameters. Just a few comments on the design: - The design features a base set of classes that won't be generated. This includes basic LLRP types, the classes that manage the connection to an LLRP device/to a client (depending on usage), and abstract classes such as LLRPMessage or LLRPParameter from which generated classes inherit (see general_structure.gif). - The names of the classes (especially of the types) are according to the LLRP specification. We propose to not adopt Java naming conventions but stick to the LLRP names, e.g. ADD_ROSPEC instead of addRospec. - All other classes will be generated using the information in llrpdef.xml and should not be manually modified after generation (marked in grey in the diagrams). - Choice parameters (i.e. list of parameters of different types) in the specification (e.g. ListOfSpecs in ROSpec 10.2.1) will be represented by generated Java interfaces (marked with the stereotype <<choice>> in the diagrams) to enhance static type correctness in the lists. We don't implement special lists but use parameterized java.util.List (see parameters_messages.gif). - Parameters that only allow certain values (e.g. ROSpecStopTriggerType 10.2.1.1.2) are subtypes of LLRPInteger that offer constants of the allowed values and perform runtime check of allowed values (see types.gif) - Encoding and decoding are performed recursively in the different LLRPParameter classes (and their LLRPParameter classes and so on) of a message. - Please note that the package structure will be changed to org.llrp.* and that minor inconsistencies in the diagrams exist since we are still in the process of implementing. We welcome any comments and suggestions! Are there any changes you would like to see to facilitate migration from the existing JAVA impl to the one proposed here that will use llrpdef.xml? Best Matthias (Auto-ID Lab ETH Zurich) Basil Gasser (Auto-ID Lab ETH Zurich) Christian (Auto-ID Lab MIT) ------------------------------------------------------------------------ - 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 ------------------------------------------------------------------------- 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
