This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/discussion/do/listPosts/projects.ggf-editor/discussion.rec_drmaa_api_spec_1_0.requested_comments_on_the_drmaa at Thu, 03 Nov 2022 23:24:55 GMT SourceForge : Post

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Project: Editor     Discussion > REC: DRMAA API Spec. 1.0 > requested comments on the DRMAA API > List of Posts
Forum Topic - requested comments on the DRMAA API: (3 Items)
View:  as 
 
 
requested comments on the DRMAA API
By: Tim Harsch - tharsch

2004-03-23 19:11  

 Hi all,
My name is Tim Harsch, I've been working on a Perl interface to the DRMAA C binding. My approach is simple, use SWIG to 
write a wrapper generator. I've just completed with alpha and plan to start calling for help from the Grid Engine 
developers list, to review my progress.
Andreas asked me to post some comments from my experience about the API. I have no working knowledge of what has 
discussed to come up with DRMAA, so this will be from a user stand point.
First, overall the spec is well defined and the documentation good. I feel there are places where the documentation of 
the C binding could have been cleared up, mostly just a few places where the English and grammer were confusing.
I only things I can think of now that need improvement are:
* I believe for each use of a char * buffer that the user should not allocate the buffer themselves, but that DRMAA 
should do it for them. This would remove the associated size_t buffer length parameter from the binding and all the 
BUFFER_SIZE constants. and simplify the interface a lot, in some functions it would remove two parameters because there 
are two buffers passed in (eg drmaa_wait )
* The attributes iterators lack some functionality (see SGE bug 908 for some background). Currently there attributes are
 of two types, vector and non-vector. I would like to see one type, where non-vector are really just a vector of one. 
And there would be functions to add and delete from the list of values for any one attribute. Any attribute where it 
does not make sense to have more than one value would return an error if more than one were attempted to be set. Or just
 silently ignore attempts to put a second value in attributes that can handle only one. This would reduce the number of 
functions for dealing with attributes, the confusion of the naming of the functions for dealing with attributes ( It 
took me awhile to comprehend which functions were for which type of attributes, because there are 'names' iterators, 
'value' iterators and vector functions can use both, etc. ).

Well, I guess that's all I can think of for now... HTH
RE: requested comments on the DRMAA API
2004-03-24 22:35  

 Hi Tim,

first of all thanks a lot for the feedback!

I agree instead of the char * buffer plus size_t buf_size approach also dynamically created strings could have been used
 with string output arguments of the C binding. Finally I guess it's a matter of taste. The reason why we decided to do 
it as it is now is that it allows the application writer decide whether the output argument is of interest or not. If it
 is no of interest then no strings are dup'd that would have to be free'd by the application. In this case one can 
simply pass NULL. Secondly the chosen approach allows static buffers of be used if desired. The BUFFER_SIZE is merely to
 be understood as a recommended minimum, because buffers of arbitrary length can be passed for those output arguments. 
We need to clarify this in the version of the C binding spec.

Regarding the attribute iterator thing I agree the chosen extend of functionality appears to be poor. However for the 
sake of providing a 1:1 C binding counterpart for the language independent spec it is sufficient. We were somewhat 
reluctant to provide more than needed. I know
the Java binding provides the means you outlined, but 
I think this is mostly because in Java world it is common to make use of language provided abstract data types that 
already provide such functionality. 

Thanks again for your comments,
Andreas
RE: requested comments on the DRMAA API
No problem.

You have valid counter arguments. I'll be having more discussions with you about Perl DRMAA binding in the future. I 
think once we get into the topic, you'll see how the attributes thing comes into play there.

 
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/discussion/do/listPosts/projects.ggf-editor/discussion.rec_drmaa_api_spec_1_0.requested_comments_on_the_drmaa at Thu, 03 Nov 2022 23:24:56 GMT