On Tue, 2009-03-10 at 12:32 -0500, Matt Brookings wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tonix (Antonio Nati) wrote: > >> Actually IMAP o POP daemons which extract from, subject, date and size > >> size must open every message to get those informations. > > While I understand where you're coming from, it's just not the path the > daemon is currently taking. In the future, once all the base features > are working, we can consider adding other features such as the ones you're > describing. > > The daemon was designed with query structure in mind, for future versions > where queries might cause query branching (eg, Commands).
This is what Dovecot does, and where my slowness is for POP. Dovecot's indexes are great, except when you're not updating them on delivery and a POP user has a ton of email. This is kinda where I was going with 'adding Dovecot support' in my first email. I was considering changing vdelivermail to have a stdout option, where you could pipe from vdelivermail to Dovecot's deliver for 'final' delivery instead of direct to Maildir within your .qmail-default file. That 'should' allow everything else to occur normally, but get those indexes updated as well. I think just 'HOME' needs to be exported, but I haven't tested it yet. > >> Also, an update of a db record could be faster than opening, reading and > >> rewriting a maildirsize file (and this cannot be done by two sessions > >> simultaneosly). > >> A centralized daemon working on quota updates also could give an > >> anourmous advantage, keeping in cache most used domains and users and > >> updating 'custom' mysql records (where domain quota could be used). > > That is what this daemon does. It replaces the 'maildirsize' functionality, > which is slow and inefficiently designed, and requires that multiple processes > work on a single file. > > The only thing it does NOT do, because it is also inefficient, is to keep a > networked database updated. The daemon itself is the networked database, but > because it does not need to parse complicated SQL statements and provide > complicated > database locking schemes, it can provide much faster access to information. > > The one thing it cannot do currently, is keep information saved if the daemon > goes > down. This will be remedied later once the current codebase is deemed stable. Maybe make it a hook to store that info in a 'database' - where by default the 'database' is memory, and add memcache and Xsql as options.. (possibly with a timestamp - older mem entries could be saved to sql after x minutes) Here I am hijacking threads again :) Rick !DSPAM:49b6ae4f32681084099638!
