I agree with the previous comments. In my opinion, code generation has in
the LLRP context one important advantage. There will be a bunch of vendor
extensions to LLRP, with different vendors supporting different extensions.
Having an XML description of these extensions and the LLRP protocol 1.0 in
conjunction with the appropriate code generators for different
implementations (java, c#) make these vendor extensions readily available to
application developers and middleware companies. Without a code generator,
manual updates to each implementations are required to support any new
vendor extensions. This might slow down the adoption of any vendor
extensions.
Not sure whether I understood this correctly but I thought that was the
whole point of llrpdef.xml.
- Christian
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of John R. Hogerhuis
> Sent: Mittwoch, 18. Juli 2007 21:48
> To: LLRP Toolkit Development List
> Subject: Re: [ltk-d] XML LLRP description
>
> On 7/18/07, Jochen Mader <[EMAIL PROTECTED]> wrote:
> > Yep, that's exactly what I proposed.
> > I know what you are doing now. But I'm not a big fan of code
> > generators for the reasons mentioned before (people start to modify
> > generated code instead of the code generator).
> > For me I like XSLT to verify content, I'm not a big fan of creating
> > code from XSLT.
> > I worked a lot wit webservices where you do that a lot and I don't
> > like it.
> > I think the place of XSLT is for verifying/validating XML.
> > For example to verify data that's being transmitted between
> two worlds
> > (e.g. C++ app talks to java app).
> > For me code generators always brought a lot of trouble.
> > But that's my opinion.
> > Cheers
> > Jochen
> >
>
> I agree, code generators are always a 'design smell.' In some
> small part, it was that design smell that led me to the
> document-oriented approach exemplified by the Perl packages.
> I managed to avoid code generation entirely in the Perl
> implementation. But I don't think there's always a good
> alternative to code generation. How would you avoid code
> generation for C, C++, C#?
>
> Note that if I were to do the Perl code over again I think I
> would actually use a code-generation approach since the
> resulting code would be faster. I'd probably do it at runtime
> so no one would ever really know. But my point is that code
> generation is sometimes an optimization tactic.
>
> In any event, keep in mind that whatever strategy we use has
> to work for other languages besides Java.
>
> -- 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
>
-------------------------------------------------------------------------
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
