[imp] simple one for the wishlist

[bill parducci]

Quoting Rich Lafferty <rich@horde.org>:
> No, it's not. It is if you use that particular mailbox format; that
> has absolutely nothing at all to do with the distribution of the
> operating system you use, the operating system you use, the mail
> transport you use, the mail delivery agent you use, or the format that
> the IMAP server reads. 

let me rephrase that: 'INBOX' is a single file if you are using redhat 7 with 
the distribution of imap that redhat supplies. it has NOTHING to do with imp. 
zero. zip. nada.

> IMP sees *IMAP*. That's all it sees. There's no reason to believe that
> mail is stored in any particular form whatsoever, or even if two users
> on the same machine store their mail in the same format. All we can do
> is ask the IMAP server for what it offers. There's no reason to
> believe we're running on the same machine that the mail is stored in,
> for that matter, or even under the same family of operating systems.

correct, i understand that imp is calling imap and is ignorant of file system 
information. i was asking for a filesystem call assuming the imap server is 
local. i realized last night that there is no gurantee that this is the case, so 
realized that the idea won't fly on that basis alone. shoot me for bringing it 
up.

again, as i said in my original message, it would be preferable that imp use 
imap to gather this information becuase it would allow you to access all 
folders and that to the best of my knowldge imap does not provide summary 
information along these lines. 

i so think it can still be done, however, i don't believe that is practical 
because i think that it would require doing summations of all of the individual 
message sizes (something i think that imap does provide) and that would likely 
tax the system/degrade response time on the page if there are a loarge number of 
users/messages on the server.

upon further examination a better solution would be to generalize the idea 
somewhat further: perhaps creating a 'placeholder variable' in that location 
that allows an admin to create a modular, customized function would work. for 
instance create a dummy include file called 'custom.inc' (<?$custom_var="";?>) 
that is called from the header page (or wherever the source is). this would 
allow those of who would like to add personalized dynamic information to the app 
to be able to do so (at least in a limited sense) without having to reverse 
engineer the app with each significant upgrade.

b