More stack traces
Sebastian at SSpaeth.de
Mon Sep 12 08:22:14 BST 2011
On Fri, 09 Sep 2011 22:04:41 +0200, Vincent Beffara wrote:
> SS> We could either add another column to LocalStatusCache table called
> SS> 'MappedUID' or 'LocalUID'. Or we could store the REMOTEU_UID ->
> SS> LOCAL_UID Mapping in another 'UIDMapping' table in the same sqlite
> SS> db.
> Another column sounds more natural
Another column, or another table (it's a relational database after all
:-)), I don't care strongly. But I really want to integrate the mapping
stuff, so we can clean up and robustify that part of the code.
> - in fact, while we are on this
> topic, is there an obstacle to having a single sqlite db per account,
> with one table per mailbox, rather than $n dbs as it is now ? Apparently
> sqlite in python can be used while multithreading.
Yes, there are obstacles. While sqlite can multithread, the current
python-sqlite bindings are often not capable of doing so (even not on my
current Ubuntu, not to speak of those people still running Python
2.5). Any handle to a database can only be used from the thread that
opened it... That's why we currently open/modify/close the sqlite database for
everything which is not optimal either.
> SS> As a third step, I would love to implement a "UID Mapping
> SS> restoration" mode which would analyze the content of mails and help
> SS> to recreate the UID Mapping if the cache is corrupted or has been
> SS> lost. THis way we can recreate the cache.
> That sounds like a great feature to have!
Yes, it would be good in the IMAP<->IMAP case, but it would also be
useful in the IMAP<->Maildir case, when you move an existing maildir in
LOCAL and you don't have the correct file names.
But obviusly, it would require us to peek into the content of each mail
and OfflineImap had never done that, so it will require some changes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the OfflineIMAP-project