2005/10/12, justin randell justin@babel.com.au:
Since RoundCube uses Pear::DB it also supports SQLite, which actually is file based. OK, it still needs the according PHP extension to work but it's an alternative if you don't have a database available.
<joke>mysql/pgsql are file based too aren't they? ;-)</joke>
Of course they are...
its a requirement for the project i'm working on, and we'd like to use roundcube, so i'm going to implement it regardless.
aside from that, i think it would be a useful addition that would bring more users to roundcube. i can understand not choosing to use a file based mechanism, but i'm not sure i understand not supporting one (provided its implementation is ok).
Sure, we can use it if the implementation is good..
It depends on how you implement it. Now the whole data reading/writing is based on SQL queries. If you have a nice way for handling both DB and file based, please post the code and we will decide.
i started on some proof of concept code in program/steps/settings/save_prefs.inc today. basically:
- wrapped the code in a save_prefs() function
- added a config option called $rcmail_config[' prefs_storage'], which
defaults to 'DB' but can be set to 'file'
- made the code that saves the data check the config value to decide
which storage mechanism to use
Sounds good.
this could be abstracted more so that the save_prefs code uses a "storage" object with a set public API to save preferences. the object could load the code for the user's chosen storage mechanism by reading the config array. however, i don't see the need for that yet - i'll leave that for further discussion and feedback.
i've started using the PEAR::File package to do the reading and writing, both because we use PEAR and because roundcube seems to as well.
i'll be working through the other code that reads/writes prefs tomorrow and i'd be happy to send some patches for perusal.
comments?
A general API for the data storage would be necessary. If you have no DB we need to store everything like address book, identities, message filter rules (will come up once) and probably caching data. To achieve this, a very flexible and extensible API will be needed.
A PGP implementation is planned for the future and it would be nice if anybody can make some suggestions for its implementation.
so is there a start on this anywhere? some design ideas? anyone else interested in implementing this?
Not yet. What needs to be configured is the local path to the PGP executables. The public keys can be stored within the address book and the identities table. To use PGP in the PHP backend I would suggest to have a look at the Crypt_GPG class: http://pear.php.net/package/Crypt_GPG
For sending the password from the client to the server our Axaj methods should do it. To increase the security we could think about implementing some client side encryption of the password but if using PGP the RoundCube server should be accessed over HTTPS anyway.
we'll be spending some time on this over the next few weeks (we implemented this a couple of years ago for the mail client we are replacing), and would like it if we can develop something that both meets our needs and is acceptable for inclusion in roundcube (whole or part).
I'm looking forward to see your work!
cheers justin
btw - is there a roundcube irc channel anywhere?
Somebody was talking about it, yes. We will post some details if it's available.
Regards, Thomas