On 27.12.2011 19:13, Thomas Bruederli wrote:
- create rcube_framework class, that can be a parent for rcmail class,
I don't get the idea behind that. What kind of functionality do you plan to put into that?
Just an idea to create a glue class similiar to rcmail, but without some Roundcube(UI)-specific methods. Then rcmail class would extend it.
Also this is a matter of naming. Would be better to use $rcube_framework (or $rcube?) variable instead of $rcmail, to make naming consistent across all framework's classes. In the app we can use $rcmail still.
rcmail is the application class and Roundcube is still an application. I totally agree to extract some stand-alone classes to form a framework for basic functionality but we should not turn the entire app into a framework. There's no real benefit for Roundcube itself and it just adds overhead to the app itself. We don't want to create another "Horde"!
I hope, we'll not lose our good performance.
- framework-related changes to existing classes, e.g.
- get rid of $rcmail object usage in classes,
This should be done for *some* classes which should work stand-alone but not for all the classes. The rcmail singleton glues all the components together and getting rid of it would require another mechanism how these components can interact with each other.
Yes, I was thinking about some places where $rcmail object's usage is simple for removal, like configuration reads or sth. For example, we can configure rcube_imap class in constructor instead of using configuration object in its methods e.g. rcube_imap::set_env(). But generally we'll need some "global" object e.g. where plugin API is used.
The idea is to make each class to have less dependencies as possible. Of course, most likely all classes will be used via framework class. So, this point is not so important. I'm just trying to have a look from framework user's point of view.
- can we exclude rcube_user class?
What do you mean with "exclude"?
Maybe we could use framework without this dependency or make it optional. I see a few places like: rcube_ldap::_connect() and rcube_imap::get_mcache_engine(), some methods in rcmail and a few functions from main.inc, using user object.
I think framework users would like to not use users storage. So, for example we could use user credentials provided in login() method. However, this will not work with enabled caching (DB structure requires users table).