[drmaa-wg] Additional error for C binding

[Rajic, Hrabri]

1023 characters for job_id is quite generous insuring that the most
majority of cases will work w/o problems.

I would not be happy if the application has a bunch of successful runs
and all of the sudden is refused job submissions because of the
inadequate buffer lengths.  

If we advise users in experience documents to bump the buffer sizes for
GT4 or similarly verbose DRMSs we could get away with error codes.

Char** avoids truncations and errors, but precludes simple buffer arrays
in favor of char ** arrays and indirect accesses.  Using 1024 characters
job_id arrays is also a poor use of memory, so we might be OK here to
complicate slightly the recommended programming model for the users.

We need to discuss this a bit more.

Hrabri

>-----Original Message-----
>From: owner-drmaa-wg at ggf.org [mailto:owner-drmaa-wg at ggf.org] On Behalf
Of
>Peter Troeger
>Sent: Wednesday, October 12, 2005 4:38 PM
>To: DRMAA Working Group
>Subject: Re: [drmaa-wg] Additional error for C binding
>
>I am not happy with such an approach. The DRMAA spec cannot assume
>how the DRMS is building its job id. For example, we might have a
>DRMAA library for GT4 where job id's are really long url's.  In this
>case it might happen that truncation is bad. The according library
>could create an own internal mapping (short id - real id), but as we
>all know this demands unwanted persistency in the library.
>
>Giving a too small buffer for an information is a problem, and this
>should be made explicit. I vote for an error code.
>
>Peter
>
>Am 12.10.2005 um 23:28 schrieb Daniel Templeton:
>
>> I knew you'd think that. :)
>>
>> I actually think that truncating the id is a better solution than
>> returning an error code, *IF AND ONLY IF* that behavior is clearly
>> described in the C binding specification.
>>
>> Daniel
>>
>> Roger Brobst wrote On 10/12/05 13:42,:
>>
>>> I think the spec should specify some constant like
>>> DRMAA_JOBID_BUFFER and the implementation should
>>> truncate the output string if a sufficient buffer
>>> is not provided.
>>>
>>> I do not think this omission merits breaking the
>>> existing C-Lang API or rehashing the underlying
>>> discussion about memory management.
>>>
>>> -Roger
>>>
>>>
>>> In a previous e-mail, Peter Troeger wrote:
>>>
>>>
>>>> Oh, Dan is now back on US time. I am the only remaining person
>>>> working at night on DRMAA ;-)
>>>>
>>>> If we can agree on the last proposal from Dan, I could add an
>>>> according test to the test suite. The first proposal would break
>>>> all existing implementations and applications.
>>>>
>>>> Hrabri, please but this on the agenda for the next phone
conference,
>>>> together with the other new issues from the last mails. Somebody
>>>> might also add a tracker item.
>>>>
>>>> Thank you,
>>>> Peter.
>>>>
>>>> Am 12.10.2005 um 21:44 schrieb Daniel Templeton:
>>>>
>>>>
>>>>
>>>>> I think the SGE implementation just truncates the job id, but
>>>>> I'm not
>>>>> sure.  My vote would be, as Hrabri fell just short of
>>>>> suggesting, to
>>>>> drop the length parameter and make the buffer a char**.  I don't
>>>>> think
>>>>> we have an error code which adequately represents the described
>>>>> error
>>>>> condition, but I'd say Invalid Argument is the best we can do with
>>>>> what
>>>>> we have.
>>>>>
>>>>> Daniel
>>>>>
>>>>> Rajic, Hrabri wrote On 10/12/05 12:20,:
>>>>>
>>>>>
>>>>>
>>>>>> There is how the spec treats a similar parameter job_name:
>>>>>>
>>>>>>   DRMAA_JOBNAME_BUFFER = 1024.
>>>>>>
>>>>>> At the other place spec says:
>>>>>>
>>>>>> job name
>>>>>> A job name SHALL comprise alphanumeric and _ characters.
>>>>>> The drmaa-implementation SHALL NOT provide the client with a job
>>>>>> name longer than DRMAA_JOBNAME_BUFFER -1 (1023) characters.
>>>>>> The drmaa-implementation MAY truncate any client-provided job
name
>>>>>> to an implementation-defined length that is at least 31
>>>>>> characters.
>>>>>> The attribute name is drmaa_job_name
>>>>>>
>>>>>> I think that the intent was to let the implementation provide
>>>>>> adequate
>>>>>> space to job_id since it was not marked as an In parameter.
>>>>>> The app
>>>>>> would copy it in an adequate length buffer (incurring performance
>>>>>> hit).
>>>>>> C-spec has done optimization here, but the adequate error code
>>>>>> is now
>>>>>> missing in the language independent spec.
>>>>>>
>>>>>> Hrabri
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: owner-drmaa-wg at ggf.org [mailto:owner-drmaa-wg at ggf.org] On
>>>>>>> Behalf
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Of
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Peter Troeger
>>>>>>> Sent: Wednesday, October 12, 2005 1:53 PM
>>>>>>> To: DRMAA Working Group
>>>>>>> Subject: [drmaa-wg] Additional error for C binding
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> the DRMAA C-binding 1.0 defines an additional parameter for the
>>>>>>> string length (job_id_out_len) whenever job_id_out is part of
the
>>>>>>> method signature. In the DRMAA spec, this is not considered -
the
>>>>>>> string is simply marked as output argument. I would be
interested
>>>>>>> what kind of error a DRMAA C-library should return of the
>>>>>>> buffer for
>>>>>>> the job_id_out parameter is too small: OUT_OF_MEMORY ?
>>>>>>> INVALID_ARGUMENT ?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Peter.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>