[RCD] Roundcube Framework

A.L.E.C alec at alec.pl
Wed Dec 28 09:29:45 CET 2011

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).

Aleksander 'A.L.E.C' Machniak
LAN Management System Developer [http://lms.org.pl]
Roundcube Webmail Developer  [http://roundcube.net]
PGP: 19359DC1 @@ GG: 2275252 @@ WWW: http://alec.pl
List info: http://lists.roundcube.net/dev/

More information about the Dev mailing list