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

[Daniel Templeton]

I decided to start digging for precedents, and I was actually surprised 
to find strong precedent for my favorite option.  The first three APIs I 
look at, JNDI, JDBC, and JAXP, all have interfaces that return objects 
of type Object when the underlying implementation is not constrained to 
particular return type.  The expectation is that the caller knows what 
he asked for and hence should know how to cast it appropriately.  And, 
by the way, if the class implements an appropriate toString() method, 
the object can be converted to a String without creating a compile-time 
dependency.  And because Java uses late binding even when casting, there 
is no runtime dependency until the code is actually executed.  If, for 
example, there's a different method for each DRM, as long as none of 
them are called, there is no runtime dependency.

JDBC also offers a precedent for the string option in the SQLException.  
In most cases, the implementation throws an SQLException and explains 
the error in the exception's error message.  Applications rarely bother 
trying to figure out what kind of exception it was.  They just assume 
that the error message will say everything that is needed.  Of course, 
in this case, the error message is most often displayed to the user, 
rather than being parsed for information.

I didn't find a precedent for the integer option, but that doesn't mean 
there isn't one.

This exercise got me thinking...  To me, the integer option is clearly 
inferior to both the string and object options.  The object option works 
great in Java and presumably in other OO languages, but is a little iffy 
in languages like C.  The string option is universal, but it's a 
universally bad interface.  Parsing output strings is only slightly more 
evolved than deciphering bit fields.  The big advantage of the string 
option is that, worse come to worse, the results can always be printed.

This brings me to two alternative options:

1) Leave it up to the language.  If string parsing is so natural in 
Python, then use strings.  In Java, Objects are obviously more natural.  
We'd probably still end up arguing about C, though.

2) Create another data type that holds a message string and an 
Object/void pointer.  If all you want is the message, you can ignore the 
pointer, and vice versa.  Of course, in a language like Java where all 
Objects have a toString() method, this option degenerates back to the 
Object option.  Maybe this option is really just the C variant of the 
previous option.

Daniel

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
>