On Thu, 10 Jul 2003, Brian Candler wrote: >> and it will reject bincimap-subscribed and accept, for instance, work/ if >> it's a Maildir. >Ah. So in the case of a file, each file would have to be opened and the >first block read, and so each file would have to start with an identifiable >signature (i.e. 'From ' for a mbox file)? >Sounds like that might create unnecessary disk I/O if there are large >numbers of metadata files. Have you seen a Maildir++ after sqwebmail, >courier-imap, courier-pop3 and isync have been at it? :-)
Yes, I have :-). Fortunately, the I/O load is IMO not significant compared to the advantage of using this design. Multiple operations on the same file do make things slower than one operation, but once one probe is made, the VFS makes multiple accesses quick by cacheing. Besides, the LIST operation, being the request that is most influenced by this design, is only used when subscribing to mailboxes, which is a rare operation. The SELECT command will use it do detect the mailbox type once during a session, which isn't bad either. Courier-IMAP's solution by having mailboxes always start with a '.' certainly filters out regular files from mailboxes, but it doesn't decide what type of mailbox it is (with Courier, it's always a Maildir anyway). We don't want to make that restriction in Binc. >Of course, Maildir++ is not IMAPdir, but if IMAPdir becomes widely >implemented and lots of programs want to store metadata, I imagine it could >be a problem. Searching and fetching (and for some mailbox formats, expunging) poses such a huge I/O impact that the mailbox detection chain sort of fizzles away, but if it becomes a performance problem then the design will naturally be reconsidered. :-) >> The advantage of this is that NNTP support (or support for any backend) >> will be easy to plug in, and the entry in the depot can then for example >> be a configuration file with host, port, username and password. This would >> allow us to support backends as loadable modules. >Sounds very cool. It could perhaps also be useful for shared folders >(especially in virtual hosting where you're not relying on Unix permissions >to control access) Yes, perhaps. :-) I like the idea also that one mailbox can hide several other mailboxes, but that's only on the drawing board right now. ;) Andy -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something | than to do it poorly."
