Quoting [Daniel Templeton] (Mar 24 2010):
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.
Hmm, I thought the problem was:
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.
The SAGA scheme would still map to C in a very simple way // create job template drmaa_job_template_t jt = drmaa_job_template_create (); // set a predefined DRMAA attribute // these calls would always succeed, basically. drmaa_job_template_set_attribute (jt, DRMAA_JOB_TEMPLATE_EXECUTABLE, "/bin/date"); drmaa_job_template_set_attribute (jt, "Executable", "/bin/date"); drmaa_job_template_set_executable (jt, "/bin/date"); // set a vendor specific attribute // this call would return an error if the attribute is not // supported drmaa_job_template_set_attribute (jt, "SGE:Executable-Type", "UniversalBinary"); // free job template drmaa_job_template_destroy (jt); So, no special rule for C, and the same drmaa2.h for all vendors. Well, the special rule for C is to have a Create and Destrpy method - but you have that for all classes/types, job template is not special in that respect... Cheers, Andre.
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
-- Nothing is ever easy.