On Thu, Jul 10, 2003 at 08:14:37AM +0200, Andreas Aardal Hanssen wrote: > >2. In the definition of IMAPdir, it says "One entry in an IMAPdir folder is > > a candidate for a mailbox". As an example, a file called "work" is shown > > as an mbox file, which maps to IMAP folder "work" > > So, how does this mechanism distinguish between mbox files, and metadata > > files like 'bincimap-subscribed', 'bincimap-uidvalidity' etc? > > When the depot object scans for mailboxes, it has a chain of > responsibility where every registered mailbox type gets a shot at > identifying the depot entry. The only supported mailbox today is Maildir, > 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? :-) 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. > 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) Cheers, Brian.
