Proposal for telling an implementation what adjacency info an app/service needs

[Tim Tautges]

There are cases where there will be variations in capabilities between implementations, without there being enough 
commonality to justify binding in the API.  The easiest example is load and save options.  In that case, an application 
must either ifdef directly to the implementation's syntax, or use a string option and test the return value of the 
function.  Either way the application will need to handle the case where the capability isn't available.  With options, 
the code is cleaner and there's a middle ground of possibly ignoring the option.

And, remember, I don't advocate doing this widely, just in a few cases where specialized behavior has far-reaching 
consequences.  I have several examples that have been encountered already, one of them resulting in bad press for ITAPS 
(the sparse vs. dense tags thing).

- tim

Carl Ollivier-Gooch wrote:
> 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
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706