Re: Use Cases

On Jun 9, 2006, at 4:18 AM, Mark Baker wrote:

>
> HTTP already provides some "design time" information too.  OPTIONS
> responses, for example.  The Allow response header.  Probably other
> things.

Maybe some agreement on terms is necessary here. I understand design  
time information to serve as a contract between client and server  
that is guaranteed to be stable at runtime. IOW, a contract that can  
go into the design, usually by more or less hardcoding it.

Having said that, could you clarify wheather why you consider OPTIONS  
and Allow to provide design time information in *that* sense.

To put this in other words: Since the server can change at any time  
the response it sends for a given OPTIONS request, of what use is  
such a response rearding any conract between client and server?

Jan

>
>>  It would help with things like
>> tooling and testing and automation, too.
>
> I think that's part of what we're trying to determine.  Having built a
> handful of machine-to-machine Web based systems, none of which needed
> a "description language" (nor would they have benefitted from one,
> IMO), I'm skeptical that there's a big enough problem here that
> requires a new standard (rather than reusing, say, XForms).  But I'm
> happy to be convinced otherwise.
>
>> > IMHO, HTTP and the shared understanding of a MIME type *and* the
>> > intention of the client developer at design time are sufficient to
>> > actually implement the client side - if the design time
>> > expectations do not hold at runtime this will be detected at
>> > runtime. (I do not consider this a problem since there cannot be a
>> > design time constraint on the runtime in a distributed system
>> > anyhow so you allways need to check and expect insifficient data)
>>
>> My experience differs.  When building a heterogeneous distributed
>> system, I'd like to have a contract that operates at a higher level
>> than a MIME type, so that when things break, you can finger-point
>> constructively.  -Tim
>
> Sorry, I don't understand what you mean by that.
>
> Mark.
>

Received on Saturday, 10 June 2006 15:19:02 UTC