[DRMAA-WG] DRMAA2: Job Sub-State Discussion

[Daniel Gruber]

In order to reduce the risk of crashing applications when using
the object pointer approach, it could be recommended to
check for the DRM implementation before accessing (or getting)
the substate.
 
Better alternative:
Because this recommendation could be overlooked
easily a new parameter for the jobStatus()/jobSubStatus() function
could be added which names the specific DRM/DRMAA implementation.
Based on this String(?) parameter the jobSubStatus() function
returns a safe null pointer (when the DRM is not matched)
or the element/class when it was matched. Sure this mechanism
could also be misused by checking for the DRM system while
runtime but for the application writer this parameter is mandatory
and he has to think about why this parameter has to be used.

my 2 cents,

Daniel

On 02/18/09 19:05, Peter Tröger wrote:
> Dear all,
>
> this discussion thread is intended to finalize the job sub-state  
> discussion from the last phone conference.
>
> Quoting from the DRMAA2 Draft2:
>
> "The jobStatus() method SHALL return the job status, together with an  
> implementation specific sub state. This is intended to be a more  
> detailed description of the current DRMAA job state, for example the  
> specific kind of HOLD state (user-triggered, system-triggered). It   
> MUST be allowed by the language binding to not retrieve this  
> information (e.g. by passing a NULL value). Applications SHOULD NOT  
> expect this information to be available in all cases."
>
> Daniel T. did a great job in summarizing the current discussion  
> status, which is about the data type for this sub-state information.
>
> We have three alternatives: integer, string, or untyped struct /  
> object pointer. All three constructs are expressible in IDL.
>
> Strings require string comparison, which is only natural in scripting  
> languages.
> Integers might look inappropriate if the language supports native  
> enumerations.
>
> In all three cases, the returned information must be interpreted  
> according to DRM-specific information (header file / type definition).  
> This normally leads to a build dependency, e.g. in the form of DRM- 
> specific string constants, numerical constants, or  type definitions.
>
> In all three cases, moving a binary DRMAA application with sub-state  
> usage to another DRM brings up a problem. With pointers, the  
> application is likely to crash (ClassCastException, SEGFAULT). With  
> integers, the application will perform wrong, since a wrong numerical  
> match occurs. With a string, no match will occur in most cases, so the  
> application will at least behave differently.
>
> Last remark: For implementation-specific JT attributes, we have a  
> lengthly discussion in the document of how to deal with DRM-specific  
> data types (introspection, late binding). This can be counted as  
> consistency argument for the object pointer approach.
>
> /Peter.
> --
>   drmaa-wg mailing list
>   drmaa-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/drmaa-wg
>