Andre, Don't worry about being biased. I'm unabashedly SGE-biased. :) Unfortunately, though, what you proposed is what we're already discussing. It's the problem, not the solution. We're trying to have a consistent API across OO and non-OO languages. The issue goes away if we just add "except in C" to the description. Andre does bring up a valid point, though, which is that we really could just special-case the non-OO languages, just like we did in v1. Or, like I said before, we could leave the template management to the implementation, scoped to the session, with an overflow value of being allowed to free templates as needed. Daniel On 03/24/10 06:03, Andre Merzky wrote:
my biased point of view: use the saga model:
{ // create job template on the stack saga::job::description jd;
// 3 equivalent ways for predefined attribute jd.set_attribute (saga::job::description_executable, "/bin/date"); jd.set_attribute ("Executable", "/bin/date"); jd.set_executable ("/bin/date");
// vendor-defined attributes: jd.set_attribute ("SGE:Executable-Type", "UniversalBinary");
// job template gets deleted from the stack when leaving the scope }
Memory management of the hash table is done internally. The implementation also needs to maintain a list of predefined attributes - but that is anyway the case I think. C language bindings could of course still fall back to the explicit create/delete methods.
Again, sorry for being biased...
Best, Andre.
Quoting [Daniel Templeton] (Mar 23 2010):
It's not a bad idea. I would really like to find a way to make it work, because it would make life quite a bit simpler. Is there a way to make it work?
Daniel
On 03/23/10 13:56, Peter Tröger wrote:
Ok, it was a bad idea. Thanks for commenting.
/Peter.
Am 22.03.2010 um 16:14 schrieb Daniel Templeton:
And that may be the original reason why the SGE C binding uses that pseudo-OO structure. It is more or less a hash map, allowing arbitrary name-value pairs to be stored, facilitating vendor-defined job template attributes. If we can't find a way around that issue, it's a show-stopper. We have to allow for vendor-defined attributes.
Daniel
On 03/22/10 07:29, Mariusz Mamo??ski wrote:
Hi Peter, all,
2010/3/22 Peter Tröger<peter@troeger.eu>:
Dear all,
we have an ongoing discussion about the possible removal of "createJobTemplate" and "deleteJobTemplate". The last proposal was to move this functions to the language bindings that need it. This is currently only C - all other languages have their own way of performing instantiation and termination explicitly.
After some more thinking, I think I got the true underlying issue. So far, we are treating job templates as instances with state and behavior - objects, in most languages. The only reason for doing this (so far) is the ability to throw errors on attribute access, since we need that for DRMAA's understanding of optional job template attributes. However, from all other perspectives, job templates are just value types. If you got one, you fill it, and then you pass the thing as a whole. In a RPC scenario, you would also expect to send filled job templates as a whole, similar to a filled JSDL document.
So if we change that, what would that mean:
C: Generic getter / setter functions for job template attributes would go away. Instead, you would create / delete JobTemplate structs directly. runJob() would take a pointer to this struct. Explicit removal is no longer needed, since the stack is cleared automatically.
C# : JobTemplate class would become JobTemplate struct.
Java / Python: JobTemplate class remains JobTemplate class, since they have no struct concept. Creation and destruction can be managed with OO mechanisms.
Another effect would be a change in the semantics of optional attributes. We already demand the syntactical inclusion of optional attribute names in the class definition. In C, the usage of a non-implemented optional attribute names gives a specialized error. With the change, we would have struct members that you are not allowed to fill in with some DRMAA libraries. But this would be detected only at submission time, since struct changes do not involve library code.
just only one concern: what if one of the DRM vendor wish to provide some JobTemplate attributes additional to those specified in DRMAA (as i remember SGE was an example)? I expect having different struct definition (different drmaa2.h ) leads to serious problems. I'm not saying no (actually having a self allocated struct in C is more convenient than using getter/setters - e.g. error handling), but this, for me, requires addressing the extension methodology on the IDL level.
And "createJobTemplate" resp. "deleteJobTemplate" ? Not needed at all then, regardless of the language.
Best, Peter.
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Cheers, -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg