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

[Peter Tröger]

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