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

[Daniel Templeton]

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