[DRMAA-WG] Treat job templates as value types ?

[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 at 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 at ogf.org
>>   http://www.ogf.org/mailman/listinfo/drmaa-wg
>>
>
>
> Cheers,