Re: [Oorexx-devel] Fwd: Need a name for a new version of RexxCreateQueue

[Chip D. <ch...@av...>]

Ah.  I see.  Then, in the immortal words of Emily Litella, "Never mind".

-Chip-

On 9/22/08 21:48 Rick McGuire said:
> 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 <ch...@av...> 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
>> Oor...@li...
>> 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
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> 
>