- Section 3

     module DRMAA {
      ...
     }

     module DRMAA  --> package org.drmaa
    
     Its probably the wrong place to ask that question, as its
     specific about the Java example, but did you consider
     org.ogf.drmaa?


   - why does the Session has an exit, while the other interfaces
     seem to have no such call?  I guess its because session is the
     only one which is expected to allocate significant resources,
     but it would be good to clarify (if that is indeed the case).


   - I wonder why you did not use the opportunity of mapping
     DRMAA to an OO paradigm to introduce a job class, instead of
     passing around the job name?
 
     i.e., you would do at the moment:

     {
       drmaa::session s;
       s.init (contact);
     
       drmaa::job_template jt = s.create_job_template ();
       jt.set_attribute ("jobName", "my_job");
       jt.set_attribute (...);

       s.run_job (jt);

       s.wait ("my_job", 1.0);
     }

     instead of tyhe alternative:

     {
       drmaa::session s;
     
       s.init (contact);
     
       drmaa::job_template jt = s.create_job_template ();
       jt.set_attribute (...);

       drmaa.job j = s.run_job (jt);

       j.wait (1.0);
     }

     Looks not that much different, but would also allow to have
     job state, job attributes etc.  directly available on the
     job class, and woudl free the application programmer from
     the need to constanty map job_name to job_templates and
     job_infos.

     A reason I can think of is persistency, as a job name can
     be used in multiple sessions, a job object can't.

     I could also imagine that this is for historical reasons,
     as that your model is simplier to map to C, where DRMAA 1.0
     is at home.  Also, I am biased as SAGA has a job class :-)

     Anyway, I am curious...


  - All in all I find that the document lives up to its goal, to
    provide an IDL rendering of DRMAA 1.0.  I see nothing where
    this IDL deviates from the DRMAA semantics, unless well
    motivated, and also see nothing which would prevent an
    implementor from using the IDL, neither for the creation of
    language bindings, nor for implementations.