Hi; I mis-spoke when referring to resource matchmaking systems as being mostly about exact matches. What I had in mind was exactly what you described and your description is much better than mine. Many thanks for the correction and improved description! I agree with you that specifying alternatives and prioritizations is difficult. Personally, I'm not convinced that specifying specific scores is much easier (having had to use such a system once). In general, I would argue that keeping things simple is most effective and that we should make sure that specifying simple common cases is both easy and efficient to do. The beauty of an evolutionary, extensions-based design is that we can start with simple approaches, layer more complex alternatives on top as desired, and then let user experience decide which extensions are actually useful. Along those lines, I think Karl's suggestion of having a binary "ignore/must-support" flag represents a relatively simple extension, whereas anything beyond would represent a much more complicated extension. Marvin. -----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Wednesday, May 03, 2006 3:16 AM To: Marvin Theimer Cc: ogsa-wg@ggf.org Subject: Re: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work Marvin Theimer wrote:
Regarding your suggestion for having a runtime meta-language for marking content as "ok to ignore" or must be understood", I have several questions/requests:
* When you say "meta-language" are you implying something richer than these two choices? I can imagine at least two answers to this question: o "Simple" (and hence also efficient) resource matchmaking typically involves (mostly) exact matches. Adding a simple binary notion of an optional resource requirement adds a powerful descriptive capability without substantially complicating the matchmaking system.
It would be so nice if that was true. Simple matchmaking comes in two varieties according to the basic type of the resource being matched. Capabilities (like the ability to run a particular application) are straight matched as described, but capacities are typically matched according to the scheme where a user wants "at least this much" and the provider has "at most that much" so it's really testing for inequality satisfiability or set overlap. What's more, alternatives are another one of these things that seems to be distinctly confusing, especially as it turns out to be very difficult for users to really understand the space of potential alternatives open to them. A better approach seems to be for users to specify their *real* requirements, and for some kind of intermediate agent to translate from those into terms understood by the resource providers.
o You want a much more expressive resource description/matchmaking language that lets you specify all kinds of complicated concepts, such as prioritization of optional alternatives.
Personally, I think that prioritization sucks. Scoring (which is sort-of but not quite the same thing) works better as it is far more flexible. It's also easier to apply to things other than the initial job request; far better to say "I prefer cheapest/quickest" after getting the tenders than to try to figure out what the space of tenders is going to look like before soliciting for them. Donal (I suspect I'm not being clear enough...)