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

[Daniel Templeton]

The reason why the job template was originally considered an "object" 
was that the original prototype (the SGE C binding) treated it like one 
internally.  (There's thing pseudo-OO data structure that permeates SGE, 
and the job template is implemented as one.)  It had to be malloced and 
freed in the prototype, which required explicit create and delete 
methods.  From the Java side, I never argued against it because the use 
of finalizers in Java is frowned upon because it gums up the garbage 
collector.

The last time we talked about it, I'm pretty sure we decided that we'd 
leave the create and drop the delete, making the job templates scoped to 
the session.  I guess you can look at that as the compromise solution.

If we make the job template a struct in C, there's no way to initialize 
it with default values.  The current SGE C binding doesn't assign 
default values either, but that's beside the point.  It could if it 
wanted to.  The Java binding does.

Having the job template as a value type only would definitely simplify 
the issue of using DRMAA as a remote interface.

Daniel


On 03/22/10 07:05, Peter Tröger wrote:
> 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.
>
> 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