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
