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 <[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
>
>
-------------------------------------------------------------------------
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
