Hi; The beauty of a "may ignore" flag is that it can be ignored. :-) So, whereas I side with Donal in believing that complex optional resource descriptions rarely work well, I side with Karl in believing that the flag should be available at the protocol level (as an extension case since I'm trying to be hard-nosed about not letting anything creep into the base case that isn't absolutely necessary for minimal interop). It's worth noting that the concept of "optionally understood" parameters is something that many consider to be one of the bigger success stories of the way the Web works (as compared to Web services). Marvin. -----Original Message----- From: Karl Czajkowski [mailto:karlcz@univa.com] Sent: Wednesday, May 03, 2006 9:07 PM To: Donal K. Fellows Cc: Marvin Theimer; ogsa-wg@ggf.org Subject: Re: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work On May 03, Donal K. Fellows modulated: ...
On the other hand, I question the extent to which an optional resource requirement has any real meaning anyway. The only times I can see a use are for when you're really trying to capture some other sense of resource by proxy, such as asking for certain operating systems with an explicit executable path instead of asking for the abstract application name that is installed at that location on those systems. But I feel that people should not ask for such proxies for what they desire; they should say what they really need (Blast, Gaussian, etc.) and let the middleware take the strain.
But aren't we defining standards for the middleware to follow (and not necessarily the people)? I think it is a HUGE mistake to keep talking about these standards efforts as if they are human interfaces. That will not give us the robust machine-to-machine communication we require, including the ability to evolve in place etc. Human information consumers are too flexible and adaptable to be the evaluation criteria for whether a protocol is going to be robust between heterogeneous software agents... The point of the "optional extension" is to allow software components to behave with graceful degradation in a heterogeneous environment. If there are basic and extended ways to describe what the client software wants/needs and the extended one is "better" but not critical to function, this allows the single message exchange to express all of that and get the best available behavior. So, I think "may ignore, but should try not to" is about the right semantics for this flag. :-) I agree that critical handling is the appropriate default for extensions. My main point is that the criticality of the extension is instance-specific to the use and NOT usually a characteristic of the extended concept itself. karl -- Karl Czajkowski karlcz@univa.com