Re: IRIP version 4 (Part 1) - DEQUEUE

[Bruce_Kahn@xxxxxxxx]

Doug replied:
>> 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 :-)

I can tell you as soon as my POP3 or IMAP client attach to the server and
begin to pull it down each time... :^b

>> 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) ?

Sounds like you are fishing to see how I implement my CS.  To date there is
no discussion in the architecture of in iRIP/iTIP/CAP about exclusivity of
access to a particular calendar at any given time like you get in, say,
POP3 while retrieving email.  I think this is an oversight that we probably
need to address somewhere before we get to RFC w/iRIP and CAP...  Thanks
for helping to tickle my gray cells on this issue (it was one of the ones I
sent in those series of blank emails last week)!

I can however tell you when my POP3 or IMAP client are retrieving email
exactly how many msgs they expect to pull down that time.  Whether or not
they 'repoll' for any new msgs depends on the way we handle this
exclusivity issue...  If I recall the older NOOP command from somewhere
(ICAP??) was used to achieve this.  Then again the sender could simply ask
"Any new/more msgs for me" when its done it if was that paranoid.  There
are simple solutions to these kinds problems... ;^)

Bruce
<missing .sig file on laptop; sigh>