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

[Andre Merzky]

my biased point of view: use the saga model:

  {
    // create job template on the stack
    saga::job::description jd;

    // 3 equivalent ways for predefined attribute
    jd.set_attribute (saga::job::description_executable, "/bin/date");
    jd.set_attribute ("Executable", "/bin/date");
    jd.set_executable ("/bin/date");

    // vendor-defined attributes:
    jd.set_attribute ("SGE:Executable-Type", "UniversalBinary");

    // job template gets deleted from the stack when leaving the scope
  }

Memory management of the hash table is done internally.  The
implementation also needs to maintain a list of predefined
attributes - but that is anyway the case I think.  C language
bindings could of course still fall back to the explicit
create/delete methods.

Again, sorry for being biased...

Best, Andre.


Quoting [Daniel Templeton] (Mar 23 2010):
> 
> 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
-- 
Nothing is ever easy.