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