On Tue, 15 Jan 2008, Marco Warga wrote:
I'm just feeling a little uncomfortable with the same DB connection beeing reinitialized each time on opening a mailbox or on atomic driver function calls like i.e. "create". This obviously makes sense for file-based mailbox drivers. However, for drivers that need some common, mailbox independent storage initialization this would be sub-optimal....
Understood. Note that, so far, nobody seems to have much luck in getting a database to be a satisfactory IMAP store. Many people have made something that "works", but "working well" is elusive.
That surprises me; but it's definitely become a patten.
I think for the first prototype, I'll stick with function-local DB connections and connections attached to the MAILSTREAMs user pointer instead of keeping a global cache.
Something that you might consider is use of the halfopen feature. That allows you to create a MAILSTREAM on a driver without really opening it (in the case of IMAP, it opens a connection to the IMAP server but does not SELECT any mailbox).
Your application can open a halfopen MAILSTREAM on your database and use that to keep the DB connection alive as other MAILSTREAMs come and go.
That way, threading shouldn't be a problem. Unless of course, two threads work on the same mailbox, which could lead to inconsistencies in the database. That would actually be the same problem with several processes accessing the same mailbox. I'll see how I can avoid this later.
Yes, it is important that you get this working. Lots of clients open multiple connections to the same mailbox at the same time, in spite of all my pleading that they do not do so.
Sounds very naturally though. Modifying i.e. the storage tables in the database while there are c-client based tools accessing it will likely result in data corruption.
You'll need some form of locking and/or share counts to keep things in synchronization.
-- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
