Proposal for telling an implementation what adjacency info an app/service needs
Carl Ollivier-Gooch
cfog at mech.ubc.ca
Tue Nov 10 19:38:10 CST 2009
Tim Tautges wrote:
> Questions:
>
> 1) What's the mechanism for registering decisions on these proposals? I
> think we have several which have had tacit approval from everyone but
> which haven't been registered yet.
>
> 2) How is the example below different than the case I've tried to make
> for string options? In each case, the implementation may or may not
> respond to the request from the service/application. It's just the
> syntax or mechanism for specifying that request that's different, but
> IIRC that wasn't a factor in the major objection to string options.
Actually the major difference is that a string option can be -anything-,
whereas in this case the argument passes specific, tightly defined
information.
That's both the strength and the weakness of a string option. You see
it mostly the strength side of that, because it opens a door to any
non-general behavior that an implementation may choose to add. I see
mostly the weakness side of it, because it opens a door to any
non-general behavior that an implementation may choose to add. (No,
that wasn't a typo.) The larger the range of possible behaviors ---
some of which may be required for a service or app to function --- the
harder interoperability becomes.
I think there's a convincing efficiency argument in this case. I'm sure
that true in others, as well. I'd just prefer to see specific syntax be
the preferred mechanism rather than a catch-all string argument.
Carl
--
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng. Voice: +1-604-822-1854
Associate Professor Fax: +1-604-822-2403
Department of Mechanical Engineering email: cfog at mech.ubc.ca
University of British Columbia http://www.mech.ubc.ca/~cfog
Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------
More information about the tstt-interface
mailing list