Christian, I just wanted to send out an email to say that we look forward to working with you on the java LLRPTK. I have been working alot with it lately with our reader emulator, but haven't looked at the code just a whole lot yet. I think Prasith is in a better position than I am to comment on how we want to go about managing and building the code so, I'll leave it to him to answer your questions about that. (He was tied up today, but I think he'll respond back later tonight or tomorrow).
However, I am pretty familiar with actually using the code, and I've noticed a couple of limitations that we'd like to address: 1)The biggest thing is the lack of unsigned data types. As you know, java does not have unsigned ints, longs, or shorts. Right now the library totally ignores unsigned datatypes. For example, if the llrp spec says something is an unsigned short, the library just uses a short for it. We need to figure out some way to address this issue (I imagine there is some standard way of handling this situation, but I haven't done enough research to know what it is). 2) We would like the library to throw a runtime exception when the user tries to serialize a message that is missing a required parameter instead of generating a default one. We feel that if a user forgot to add a required parameter, he made a mistake. Adding a default parameter in this situation only obscures errors. Thanks, and I look forward to working with you on this. -Kyle Neumeier On Thu, 2007-07-26 at 12:52 -0400, Christian Floerkemeier wrote: > Paul, thanks for the introduction. > > Prasith, we started work on a Java LLRP library implementation a couple of > weeks ago with Basil Gasser, a student at the Swiss Auto-ID Lab, doing most > of the coding. Previously, we had already implemented EPCIS, TDT, RP, ALE, > and RM and made them available as open-source at www.accada.org . > > When the initial JAVA code from U of A got committed we noticed a couple of > things that we considered not ideal: > * it is not using LLRPdef.xml > * the code generator is passive - it requires manual tweaks. IMHO this is a > big issue from a maintenance perspective - especially when the generated > code gets checked into cvs as it is currently. > * the code generator mixes parsing with code generation > * not sure whether all of LLRP is actually supported > > I tried to raise some of the points on the mailing list earlier, but except > for John and Gordon (perl and c++), there was no reply from the Java > developer(s). Just wondering whether you agree with my comments above? > > Here is our current thinking: > > - Generate the LLRP Java Library using Apache Velocity (if this does not > work, we'll build a java code gen) > - Use LLRPdef.xml > - Output a set of classes with public methods which will be identical/very > similar to the U of A code. I don't think the LLRP spec leaves a lot of room > there. > > Does this make sense? > > - Christian > > -- > > Christian Floerkemeier PhD > [EMAIL PROTECTED] > Auto-ID Lab, Massachusetts Institute of Technology > phone: +1-617-324-1984 > > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul > Dietrich > Sent: Donnerstag, 26. Juli 2007 12:02 > To: [email protected] > Subject: [ltk-d] Java library (ies) > > > > We’ve seen interest from multiple parties for Java library > development. I want to ensure that our toolkit Java resources are being use > to produce the best library we can. > > > > I think it makes sense for Christian, Prasith, Kyle, and any other > that are interested in *developing* and *supporting* Java to engage in > discussion here on how to move forward with the Java toolkit(s). > > > > I have seen discussion on the merits of code generation, but I don’t > think there is any disagreement that if we are using code generation, we > should use the Common machine descriptions. Is there any other technical > justification to have two separate java toolkits? > > > > If there is not sufficient technical justification, what is involved > in merging this new effort with the existing one? > > > > Regards, > > > > Paul > > > > > > > > > > ------------------------------------------------------------------------- > 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
