Hi; If you structure things to explicitly support evolution and extension then I believe you get the desired effects: - Simple base case - Extensions that selectively and optionally add richness while building on the base - An explicit sanction to make early progress on the simple, well-understood parts of a problem without preventing future evolution to richer, more complete solutions. Marvin. -----Original Message----- From: Alexander Papaspyrou [mailto:alexander.papaspyrou@udo.edu] Sent: Friday, June 09, 2006 4:24 AM To: Michel Drescher Cc: Karl Czajkowski; Donal K. Fellows; Marvin Theimer; JSDL Working Group; ogsa-bes-wg@ggf.org; Ed Lassettre; Ming Xu (WINDOWS) Subject: Re: [ogsa-bes-wg] Re: [jsdl-wg] Questions and potential changes to JSDL, as seen from HPC Profile point-of-view Michel Drescher wrote

...

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*

I also agree. From a user's POV, I pretty much don't care on what resource (within the constraints I specify) the job is run, just that it is at some point.

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:

I'm unsure whether one needs *two* different resource models here.

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

I think this observation is correct. The whole idea is that the user does not care about the specific resource, but only about a defined TOS (type of service, for the non-acronym impaired), and even then, only regarding the proper (and potentially early) execution of his job.

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.

Maybe this can be covered by one "language". Then, one would need to specify two, let's say, versions of it: - the provider version, which should be strict to ensure accurate descriptions of their service's capabilities and - the consumer version, which is more relaxed in terms of allowing to leave out certain parts in order to be able to specify "loose" constraints for their service requirements IMHO, this would cover what Michel suggested, but make life easier for the involved WGs (not having to maintain two languages which are more or less identical) and -- later -- for the implementors (not having to provide two libraries for more or less the same functionality). Furthermore, the match maker people wouldn't have to suffer that much... Greetings, Alexander -- Dipl.-Inform. Alexander Papaspyrou | 44221 Dortmund, NRW (Germany) Robotics Research Institute | phone : +49(231)755-5058 Information Technology Section | fax : +49(231)755-3251 Dortmund University | web : http://www.irf.de/