These are C APIs I'm talking about. It's not possible to add an
option to these and maintain binary compatibility with existing
applications. A new API that behaves the way we wish it to behave
really is the only option.
Rick
On Mon, Sep 22, 2008 at 5:13 PM, Chip Davis <[EMAIL PROTECTED]> wrote:
> Well, you know you can trust me to have an orthogonal take on this...
>
> IMHO, the only problem with the OS/2-style RexxCreateQueue is that it tries to
> subsume two discrete operations: 1) verifying whether a queue by the supplied
> name already exists, and 2) creating a new queue.
>
> This is a fine idea if most of the time, you simply want to create a queue and
> don't care what it is named. One call to RexxCreateQueue and a uniquely-named
> queue is created, the name returned to you, and you're off to the races.
>
> However, if you simply want to verify that a specific queue has already been
> created, it still takes two operations because sometimes the first step will
> have created a new queue that you don't want, so now you must delete it.
>
> Also, if you want to create a specific named queue, it often requires a
> minimum
> of three operations: 1) attempt to create a queue by that name, 2) verify
> that a
> queue by that name doesn't already exist and if so, delete the uniquely-named
> queue created by step 1, and 3) come up with different name and try again. If
> you do this in a loop and append an index to the name to attempt to make it
> unique, this could go on for quite a few iterations.
>
> On the face of it, this is exactly the same problem as creating a temporary
> work
> file. When you open "temp.wrk", the return code tells you whether or not a
> file
> by that name already exists. The open operation doesn't automagically create
> a
> "temp.wrk1" that you have to come back and erase if you don't want it.
>
> So rather than create a whole 'nother RexxCreateQueue (which is the perfect
> name) why not simply add an option to make it return a null string instead of
> mindlessly creating a unique queue? That separates the query operation from
> the
> create operation, and avoids having to come up with yet another very similar
> function with a slightly different name.
>
> This would kill several birds with a single stone. If the major objection is
> the automatic creation of a unique queue, that behavior can be suppressed in
> favor of a string such as Stream('temp.wrk','c','query exists') returns. It
> also satisfies the RFE for a RexxQueueExists operation. And it would be
> backwards-compatible in exactly the same way as the explicit OPEN and CLOSE
> operations were added to Stream.
>
> It seems to me that any conceptual parallelism between the Queue and Stream
> operations should be exploited.
>
> -Chip-
>
> On 9/22/08 13:31 Rick McGuire said:
>> Given that this has all been rewritten anyway, I'd like a "do over" on
>> something I did 20 years ago. The RexxCreateQueue API will create a
>> new queue with a unique name if the requested name already exists. I
>> really don't remember why we decided to do it this way with the
>> original OS/2 implementation 20 years ago, but I have a vague memory
>> that it was something the OS/2 people wanted. Frankly, this has
>> generally not worked out real well. In most cases, the create
>> operation is called for the purposed of creating the queue if it
>> doesn't already exists. The current behavior means the caller need to
>> check the returned name and then delete the additional queue if one
>> was created. Generally, a pain.
>>
>> I'd like to create a new version of the API (and expose it in the
>> RxQueue() function and the RexxQueue class) that behaves the way
>> people generally want this to work, which is to make sure that the
>> queue exists. This is fairly easy to do....the biggest hang up is
>> what to call the operation? The best I've come up with so far is
>> RexxOpenQueue(), but it's not create an open operation.
>> RexxGetQueue() might also work, but a Get implies something is
>> returned, which is not really the case.
>>
>> We have an RFE for an exists operation also, so I'll probably add a
>> RexxQueueExists() API at the same time.
>>
>> Rick
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
