Re: Code generation or forms?

On Jun 2, 2005, at 9:11 PM, Mark Baker wrote:
>
>> Why would this be in any way different? Whether you generate code at
>> development time or interpret it at runtime shouldn't make a
>> difference. The more information the description contains, the more
>> meaningful you can interpret it or generate code from it.
>>
>
> I've gone back and forth on this issue for a while.  What I think my
> biggest concern boils down to is that there's a lot of, for example,
> existing HTTP libraries which are very mature, stable, and highly
> optimized.  If a description language came along which included
> information targetted for code generation which overlapped in scope
> with code already within these libraries, then they will be
> incompatible, and the library in need of change to support the
> description language.  Not a good thing ... unless you're an ISV  
> trying
> to reduce competition with open source alternatives by decommoditizing
> this part of the stack, I guess 8-).
>
The code I'd typically generate would just wrap an existing HTTP  
library and provide some application-specific value add on top of the  
existing library. I don't really forsee much need to generate the  
entire HTTP stack for each web app, that's what libraries are for.

Marc.

> That's not to say I'm against supporting code generation entirely,  
> only
> that I think each proposed feature will need to be examined closely  
> from
> this POV.
>
> If I had my way though, we'd be starting out from the assumption that
> all information in the language is for runtime consumption.  In  
> fact, I
> wonder why that isn't the default position of this group, since the  
> Web
> currently works just fine in this manner, and I know from experience
> that you don't need a description language(*) to develop very large
> (international scale) machine-to-machine solutions.
>
>  (*) you do need a forms language though
>
> Mark.
> -- 
> Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
> Coactus; Web-inspired integration strategies   http://www.coactus.com
>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.