cache -> maybe it will be better to store the cache data on some other sort of file based database (plain text file, dbm, sqlite ...) This will be faster than using a server based relational database and will end with problems related to size of records.

Problems with the record sizes could probably be mitigated by changing the way the data is cached. I haven't looked into the code for this so i could be totally way off base and wrong and if so just call me on it =). The SQL queries should be pretty fast, flat files usually take longer to parse than doing an SQL query -- especially for large amounts of data/records.

If the caching was, for example, one record per message in a table of messages, that would probably help. Even splitting the message components up into headers (one table column per), body and attachments (if those are even cached). Each message would have additional metadata associated w it: roundcube user, imap server, folder, timestamp (for cache expiry).

Jeff

2005/10/28, David Saez Padros david@ols.es:

cache -> maybe it will be better to store the cache data on some other sort of file based database (plain text file, dbm, sqlite ...) This will be faster than using a server based relational database and will end with problems related to size of records.

I am agree. Temp files (in any format) is ok to me.

addressbook -> it should have it's own database backend, many people would like to use it's ldap server for this (many already do that yet), maybe in adition or replacing the current per user addressbook

I will propose 3 options:

1- (default) Per user addressbook (As it is now). 2- Per domain adressbook (similar to the current config, but a shared addressbook can be used). 3- LPAD or similar.

Using simoultaneously option 1 and 2 would be a good idea :-)

-- Andres Jimenez Dublin Institute For Advanced Studies