[ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work

[Marvin Theimer]

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 at univa.com] 
Sent: Wednesday, May 03, 2006 9:07 PM
To: Donal K. Fellows
Cc: Marvin Theimer; ogsa-wg at 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 at univa.com