On 7/4/07, Joseph E. Hoag <[EMAIL PROTECTED]> wrote: > > > > However, if we decide that human-readable communications (i.e., XML > messages) need to be supported (in addition to byte streams), then it will > probably become important to get align class names and parameter names > between languages. This is accomplished more easily if all languages > generate off of a single class description file. > > Let's be realistic, though -- tweaking class names and method > names/signatures in a library is more or less the same as replacing the > entire library in terms of the pain that it will cause developers. If the > Java library is tweaked to look like the C++ library (in terms of > class/method naming), then it essentially becomes a new library, and users > (like TagCentric and Rifidi) will need to spend considerable time re-writing > to conform to the new library. >
I am not sure I agree with that... the actual names used when binding to a library is not hard to change. It is much harder to switch libraries altogether, since with a new library comes a different class hierarchy, set of interfaces, memory management strategies, synchronization issues, etc. Changing names is a search and replace operation. Changing libraries has an aspect of design to it. I think it would be a mistake for the Java library to be forced to "look like" the C++ library. Certainly the Perl library to be contributed doesn't look anything like the Java or C++ library. Each language is different so naturally the APIs will be different. That said, the underlying concepts are invariant, since all these APIs end up talking binary LLRP. So there can be some level of commonality. Probably the names of enumerations messages, parameters and fields is about all we can hope for. Even then, I can imagine issues of camel-casing vs. lowercase, etc. problems where the culture for a particular language will dictate. When that cannot be automatically inferred from standard names, we could conceivably provide alternatives in the schema. > Do we really need to develop a de-facto XML LLRP messaging standard (with > standard element names and formats) to go along with the byte-stream LLRP > messaging standard? This is debatable, and may cause more problems than it > solves. But if we decide that the answer is yes, then we probably want to > merge the class description files sooner rather than later. > Having been using this format for the last several months, I find it indispensible. Having a textual represenation of LLRP, along with XPath, and some code to manage the TCP link, has served us like a domain-specific programming language tailored to LLRP. And the social aspect of being able to communicate about LLRP in an unambigous is hard to overstate. What kinds of issues do you foresee with the abstract schema? -- John. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
