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

[Mariusz Mamoński]

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,
-- 
Mariusz