Re: IRIP version 4 (Part 1) - DEQUEUE

[Bruce_Kahn@xxxxxxxx]

Doug replied (in part):
>> Issuing the DEQUEUE command changes the protocol to the Receive state.
>> The receiver replies with a single queued [ITIP] request or a status
code
>> to indicate that there are no more queued requests for the authenticated
>> user.
>>
>> Poor choice of actions.  This prevents a CUA from properly indicating
>> progress as it can only say "Im getting another iTIP msg of some unknown
>> quantity" (ie: the candy cane progress bar) instead of the actual
progress
>> bar.  See comments above about POP3's LIST.
>
>1) Orthogonal - No such limitation. A progress bar can be updated
>   by the code that is getting data. Or you could thread your app.
>
>2) iRIP is designed for CS <-> CS communications.

1: The progress bar is not a progress bar if the sender CS has NO (zero,
NIL, NULL) ways of knowing how may other entries are available; all a
process can do is say "Processing yet another reply...".

If I send a reply to a message, can you say w/ANY certainty (luck excluded)
that it is "reply 1 of 32"??  I doubt it.  If you can, you should get your
own 1-900 #.

The suggestion of a LIST, COUNT or DEQUEUE_COUNT command that simply
returns a response code and numeric value still stands.

2: Correct, it was late and I misspoke.  iRIP is CS<->CS (of course my CUA
could have a CS built in as per Franks comments of long ago :^) )

Bruce