Hi all,I have combined Peter’s and Daniel and my notes into one set of session minutes.	HrabriShort introduction – Hrabri Rajic:* DRMAA recommendation document in the 2nd public review period* we have SGE & Condor reference implementation* multiple implementations are always goodC and Java bindings – Daniel Templeton:C-Binding :* easy mapping from the spec* DRMAA-enabled SGE in beta test, DRMAA library on-top-of SGE job submission library* next DRMAA version -> integration of JSDL ?!* DRMAA compliance test as C-file (good idea, similar to Java Community Process)Java-Binding:* one Java package for multiple implementations* multiple packages for multiple implementations on one machine is difficult (class path problem)* solution: factory pattern for Java language binding* CreateJobTemplate() method exists, even though a job template is an object instance that can be instantiated by the language   (allows custom action during creation)* some DRMAA errors exist in the Java world (e.g. OutOfMemory), Java-DRMAA reuses them* Security is an issue for implementation.NET Binding – Peter Troeger* Initial goal: Find an OGSI.NET frontend for job submission to a    Condor cluster, based on existing library* .NET language mapping for DRMAA w/o consulting Java binding work* IDRMAA interface, just 1! + several job classes using .NET naming* Use enumeration more instead of string values for states* .NET proposed approach similar to Java binding approach* Exceptions in flat space, like Java ver 0.1 bindings setup* .NET doc for DRMAA available* MONO on Linux rather impressive as an Open Source project and already useableOpen floor – Hrabri chairing:Relations to other groups:* ask DRM programmers what they want* Overlap with SAGA group, OGSA PE subgroup, workflow * DRMAA Globus binding -- promising approachSuggestion from the audience:* Scheduling people need functions for querying the actual state of long-running jobs ( runtime performance data, ... )* Hrabri: There is more than one missing feature (logging, workflow, ...)* ideal thing would be a "performance contract"* state of the art: application measures performance data by itself during execution* getting rusage info for a running job to determine what next* evaluate having mutable job templates even updating attributes during the execution* more flexibility for the jobs