Re: IRIP version 4 (Part 1) - DEQUEUE

[Doug Royer <Doug.Royer@xxxxxxx>]

> From: Bruce_Kahn@iris.com
> Date: Sun, 21 Mar 1999 19:55:19 GMT
> 
> 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 you can tell me how many email you are going to get today,
then I'll believe this is achievable in calendaring :-)

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

What if 1 more is queued after you ask (from another thread, or
perhaps someone has pushd iCalendar data for you and you have
to poll for it) ?

-Doug