- From: Paul Downey <paul.downey@whatfettle.com>
- Date: Fri, 3 Jun 2005 14:52:21 +0200
- To: Mark Baker <distobj@acm.org>
- Cc: public-web-http-desc@w3.org, Stefan Tilkov <stefan.tilkov@innoq.com>
On 2 Jun 2005, at 21:11, 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. and there are a lot which are incomplete and full of bugs and work-rounds and optimisations for bugs in particular in well known implementations. > 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-). > i don't understand how this relates to code-generation, how messages are produced and consumed is essentially looking 'behind the curtain'. > 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. OK, agreed! > If I had my way though, we'd be starting out from the assumption that > all information in the language is for runtime consumption. Is that because the service is likely to change in an incompatible way between a description being read and used to communicate with the service? In which case all that assumption does is shorten this window of failure. Or maybe i'm missing your point here. > 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. 'Generating' code, agents, validators, test forms, documentation, whatever seem to be very interesting uses for a formal description. > (*) you do need a forms language though you could still generate code from forms, though unless there is some indication of the content of responses you might expect, or negotiate, it's not that useful. -- http://blog.whatfettle.com
Received on Saturday, 4 June 2005 08:45:28 UTC