Conference call - November 23th - 19:00 UTC

Dear all,

since the public comment period for DRMAAv2 is now over, we need to 
discuss our reaction on the comments. The next DRMAA conf call is 
therefore scheduled for December 7th, 19:00 UTC.

We meet on Skype, please find me under the nickname "potsdam_pit".

Preliminary meeting agenda:

1. Meeting secretary for this meeting?
2. Remaining public comments on DRMAAv2
(http://ogf.org/gf/docs/comment.php?id=377)
3. Next steps with the C-binding

Best regards,
Peter.

Meeting minutes - Conf call <at> November 30th 2011

Participants: Mariusz, Daniel, Roger, Peter

> 1. Meeting secretary for this meeting?

Peter

> 2. Public comments on DRMAAv2
> (http://ogf.org/gf/docs/comment.php?id=377)

-> "slots" attribute in SlotInfo

- Just a typo, proposed solution approved.

-> Attribute naming

- Agreement to stick with self-descriptive attribute names
- Agreement to current shortening approach in C binding draft:
   - drmaa2_reservation_get_reservation_id (bad duplication)
   - drmaa2_r_get_reservation_id (we like this approach)
   - drmaa2_r_get_id (not self-descriptive enough)

-> exception extensibility

- Extensibility of exception list in language binding or implementation
- First one is easy (e.g. special expression of runtime issues in JVM)
   - Does not break portability
- Allowing extensibility in implementations can break portability
   - normally,  we have introspection support for this
   - Fetching the list of implementation-specific exceptions is useless
   - Customer perspective: I want portability

Conference call - December 7th - 19:00 UTC

Corrected the subject line, sorry for the confusion.

Best regards,
Peter.

Am 05.12.11 17:31, schrieb Peter Tröger:
> Dear all,
>
> since the public comment period for DRMAAv2 is now over, we need to
> discuss our reaction on the comments. The next DRMAA conf call is
> therefore scheduled for December 7th, 19:00 UTC.
>
> We meet on Skype, please find me under the nickname "potsdam_pit".
>
> Preliminary meeting agenda:
>
> 1. Meeting secretary for this meeting?
> 2. Remaining public comments on DRMAAv2
> (http://ogf.org/gf/docs/comment.php?id=377)
> 3. Next steps with the C-binding
>
> Best regards,
> Peter.
>
>
>
> --
>    drmaa-wg mailing list
>    drmaa-wg@...
>    http://www.ogf.org/mailman/listinfo/drmaa-wg

Meeting minutes - Conference call - December 7th - 19:00 UTC

Participants: Roger, Mariusz, Peter

>> 1. Meeting secretary for this meeting?

Peter

>> 2. Remaining public comments on DRMAAv2
>> (http://ogf.org/gf/docs/comment.php?id=377)

- scalar attribute question
	- demands copying of strings, implement via const char*

- native types question
	- decision has to be done by language binding

- slots question
	- slots count should be numeric, is a typo

- SessionManagementException question
	- left over, remove from IDL

- exception raise clause question
	- sad fact, but the group cannot deliver a reasonable list now
	- will come with existing implementations at grid recommendation phase

- DRMAA_JOBID_VAR
	- makes sense, add it

>> 3. Next steps with the C-binding

New DRMAA co-chair

Dear all,

since some of you might have missed that from the last meeting minutes:

DRMAA has a new co-chair, Mariusz Mamoński from Poznan Supercomputing 
Centre. The Open Grid Forum Steering Group already accepted the shift. 
Mariusz is replacing Daniel Templeton as DRMAA co-chair, who stepped 
back from the position due to real-wor(k|ld) overload.

The group wants to express its deep gratitude to Dan for years of 
continuous support and personal engagement. We are aware of the fact 
that Dan (together with many other Sun employees) acted as the major 
driving force behind the market acceptance of DRMAAv1. Hopefully, he 
will continue to "just talk a lot" as regular working group contributor. 
And we still want the DRMAAv2 Hadoop binding  ...

Best regards,
Peter.

--
  drmaa-wg mailing list
  drmaa-wg <at> ogf.org
  http://www.ogf.org//mailman/listinfo/drmaa-wg

DRMAAv2 C binding - General style decision

Dear all,

in continuation of the conf call discussion, I asked Andre for a summary 
of the API style possibilities in the C binding. We currently have a 
model were the C equivalent of an IDL function is returning a typed 
result value, while the C equivalent of an IDL procedure is returning a 
typed error code:

drmaa2_job_template_t drmaa2_j_get_job_template (drmaa2_job_h j);
drmaa2_error_t        drmaa2_j_suspend (drmaa2_job_h j);

Here is Andre's statement:

--- snip ---

IIRC, the assumption was that we need to always be able to determine an
error condition.  For example:

   drmaa2_job_info_t drmaa2_job_info_create (void);
   drmaa2_error_t    drmaa2_job_info_free   (drmaa2_job_info_t ji);

The create can of course fail.  In that case, the error will be
signaled by returning a NULL pointer -- remember that

   typedef drmaa2_job_info_s * drmaa2_job_info_t

The free call is, in idl, void, and thus could not flag an error.
Thus we made it return that flag explicitly.

That is similar to what many unix calls do, for example:

Latest C Binding Proposal

Dear all,

please find attached the updated DRMAAv2 C binding proposal, considering 
the latest conf call discussions.

The updated root spec (after public comment period) was submitted to the 
editors, and is most likely to become an official standard in January.

I would like to thank everybody for the great work during this year. We 
managed to finish a major piece of work with the DRMAAv2 root 
specification. The next year will definitely be even more exiting, when 
we tackle the implementation front.

I wish everybody a peaceful and relaxing Christmas time ! Calm down, and 
get yourself some rest ...

Best regards,
Peter.

/* DRMAAv2 C Binding
 * Authors: Andre Merzky, Mariusz Mamonski, Daniel Gruber, Peter Tröger, Roger Brobst
 *
 * Open issues are marked with FIXME
 *
 * Design decisions:
 *  - IDL module scope is realized by "DRMAA2" prefixing of names / identifiers
 *  - If the input type gives all information, the parameter and method name are shortened
 *  - IDL-spec data types get an "_t" postfix to their name