Karl Czajkowski wrote:
One thing Donal mentioned which I would like to emphasize:
The discovery ought to be "what types of job are acceptable" and not what resources are there. Or rather, the latter is part of some administrative interface which is misleading for job-submitting users and middleware.
Yes! Yes! *waves the supporting flag*
This may sound pedantic, but it will be crucial for interop. The discovery has to capture realistic operating policy, and not just give enticing catalogues of resources which can never be combined in a single request!
Hit base. After reading this mail, we are probably best fitted if we provide *two* resource models. Which may sound impractical, wasted resources or even impossible, I think the idea may be worth exploring: (Note that I take quite some assumptions for granted for the sake of simplicity:) While system administrators are interested in making the best use out of their machines (simple reason: return of investment), job submitters are interested in having their jobs actually executed rather than optimised 'til the last percent (while I acknowledge that there actually are submitters that do want to or even need to optimise that way, I think that this is a relatively small subset of Grid users at least in the future). A solution to this dilemma may be to provide two "languages", one fitting each group best: One language that job submitters use to specify resources they need, which sacrifices accuracy for practicability. This can be very simple, even name/value pairs. The other language, however, aims for maximum accuracy that I envision to be a feature rich, (strongly?) typed representation of their resources. Obviously, these two languages need matching when a job is submitted. The natural candidate for that is (Donal, forgive me for inaccuracy here) "something" coming from the RSS WG. Any boos, rotten eggs? Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834