Re: Code generation or forms?

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