The closest to this are the "open" and "close" methods. The driver
must be open on that mailbox before calling the close, fast, msgflags,
overview, structure, header, text, msgdata, uid, msgno, flags,
flagmsg, search, sort, thread, ping, check, expunge, copy, and gc
methods. The other methods (valid, parameters, scan, list, lsub,
subscribe, unsubscribe, create, mbxdel, mbxren, status, open and
append) do not require a previous open.
True. This case is easy, as I can store the connection on the
MAILSTREAM's user pointer.
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....
Note that open may be called on a MAILSTREAM that is already open.
This does an implicit close followed by a re-open with a new name.
Thats ok, the bundled drivers check for this case so I guessed that.
It depends upon whatever application calls c-client. c-client itself
does not use threads, but there is an effort to make it thread-safe.
Note that some objects (particularly configuration settings) in
c-client are globals and thus are generally set at startup before
spawning any threads. If you alter them while threading, take care
that you want the alteration to take place in all threads.
Thats what I wanted to know. I am aware that theres no threading in the
imap toolkit itself, but if there are efforts to keep c-client
thread-safe, then the drivers have to be kept thread-safe, too.
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.
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.
The other thing that you need to keep in mind that c-client inherits
statefulness from IMAP. Unlike protocols such as HTTP or NFS, IMAP is
a highly stateful protocol and once a mailbox is open, changes to the
mailbox have to go through the defined mechanisms of IMAP and
c-client. You may not understand this, or why it is important, now.
Trust me, by the time you finish your project, you will.... ;-)
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.
Read the file .../docs/internal.txt for more information about
drivers. This document is sadly out of date but most of the
information is good.
I'm not sure how I could overlook this file. Sorry :-)
Thanks for your help,
Marco
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
