As you know Pramari is building an llrp reader emulator based of the epc spec. We are currently using the java llrp toolkit code to do the translation between classes and bytes and vice versa. Recently we have been thinking about the error checking of messages, and I wanted to see how the other projects (c++ etc) are going to handle this.
When the client forms a message (for example an ADD_ROSPEC), you have to create an object like this: AddROSpec aros = new AddRoSpec(); Then you have to create parameters, set values and add them to the parent object like this: ROSpec rs = new ROSpec(); rs.setROSpecID(10); .. set more rospec params and fields .. aros.setRoSpecParam(rs); As you can see, there is alot do do here; there ends up being about 40 lines of code to create a ROSpec if you want to set all the various parameters. It would be easy -- especially in the early stages of testing and development -- to forget to create a certain parameters or even just to forget to add it to its parent object. I assume for the other projects, something similar will be necessary. The java classes that we are using create default objects automatically with default values for required parameters to enforce compliance. From our point of view, however, this could cause problems, because a user could be looking for some specific behavior, see that that behavior is not exhibited even though he has set the value (for example a timeout value or a boolean value in the reportspec), when in fact he made some mistake in forming the message (like forgetting to add it to the parent object). No runtime error (a NullPointer or IndexOutOfBounds etc) will be generated because the llrp toolkit java classes automatically created default objects; the problem will be much more difficult to debug than it has to be because the user can't tell immediately if it is a problem with the message or a problem with our reader emulator. We are proposing a change in the java llrp-toolkit classes so that runtime errors are thrown when messages are serialized (from objects into a byte array to be sent on the wire) if the user forgot to supply a required object instead of default parameters being used. We also want to get other's input on this issue and see how other projects are planning on handling this problem. This will also give us a chance to figure out some sort of a process for making changes to code and such.... Thanks, Kyle ------------------------------------------------------------------------- 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
