- From: Mark Baker <distobj@acm.org>
- Date: Thu, 2 Jun 2005 15:11:44 -0400
- To: Stefan Tilkov <stefan.tilkov@innoq.com>
- Cc: public-web-http-desc@w3.org
Hey Stefan, On Thu, Jun 02, 2005 at 08:18:37PM +0200, Stefan Tilkov 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-). 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
Received on Thursday, 2 June 2005 19:11:19 UTC