[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IRIP version 4 (Part 1) - LIST command



Splitting this thread into multiple parts to make it more readable...

Doug replied (in part):
>> Also, how does my CUA speaking iRIP know how many there are (ala POP3's
or
>> IMAP's LIST command).
>
>When EMAIL is queued - can you tell? - No.

Sure, check out the LIST command in POP3 and IMAP.  This is current MUAs
are able to put up progress bars...

>The primary usage for iRIP is CS <-> CS, although there is nothing
>from keeping the CUA from using iRIP.

Missed my point.  If the sender must just keep doing DEQUEUEs until it gets
a "No more messages" error reply, there is no way for them to indicate
partial progress of any kind ("server" or "client").  Being able to
indicate partial progress is VERY useful in deciding if a
connection/process should be prematurely terminated or not.  It also is
VERY VERY useful for guestimating the estimated time left in the
operation!!

Please reconsider adding some command for this!  It will make the users
thankful and its very useful feature.

>>  In POP3 I can do a LIST and then RETRieve just msg 3 of 30 if I
>> wanted to.
>
>iRIP servers are not alternate storage systems for CUA's. They simply
>allow you to work out through a firewall or disconnected system...

Again, point missed.  Having some way for a sender to indicate progress and
do stuff like guesstimate when the work may be done is VERY useful to
admins.  Since the receiver very likely has some knowledge of how many
queued replys are ready to be sent back, why not 'share' this info
w/someone who may want to use it??!  Im not suggesting this "end user"
feature for use in a CUA, Im saying its also useful as a feature in
implementing a CS as well!

>> This new ability would increase the complexity of your Send
>> state but not by much.  It would however make the UI more user friendly.
>
>However what you are describing are CUA needs. I would suggest they
>may be out of scope for iRIP.

I disagree w/that last part.  The needs are not just CUAs but also CS's.
Knowledge about what is queue'd to you (the CS) is VERY useful in stuff.
iRIP is a binding of iTIP and a real time engine can easily apply knowledge
about its workload to do tasks more efficiently or smarter.  A new "LIST"
or "COUNT" or "DEQUEUE_COUNT" (etc) command that simply returns the # of
responses that are currently queued is easily allowable as an 'admin' part
of the binding.  (Im not asking for an exact POP3 LIST w/octet sizes, etc.;
just a response saying "You have 153 replys queued"...)

Bruce