[RCD] Roundcube Framework

Thomas Bruederli thomas at roundcube.net
Tue Dec 27 19:13:10 CET 2011

On Tue, Dec 27, 2011 at 09:17, A.L.E.C <alec at alec.pl> wrote:
> Besides the new skin in 0.8 I'd like to start working on Roundcube
> Framework. It means Roundcube will provide a set of classes that can be
> used by other projects. Now, rcube_imap_generic class is known as one of
> the best IMAP handling classes, but there are people that would like to
> use something more abstract i.e. rcube_imap class. This is not simple
> now because of its dependencies.

Sounds good!
> So, here are some steps I want to make:
> - create abstract rcube_storage class and build rcube_imap as
> rcube_storage implementation (driver) - this is to allow creation of
> other drivers, e.g. SQL-based, POP3,
> - exclude mime related functions from rcube_imap into new rcube_mime class,
> - split main.inc and rcube_shared.inc functions into a few classes:
> rcube_converter, rcube_ui, rcube_utils and maybe some into existing classes,


> - 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?
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"!

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

>   - can we exclude rcube_user class?

What do you mean with "exclude"?

>   - make output/html/template classes optional,

Again, IMO not all classes/components need to be turned into a
framework. These output classes are part of the application. Of course
they could be streamlined to provide a more general interface to the
various output types.

> - unify codestyle according to our CS ruleset

Agree, but please keep in mind that reformatting code will make it
harder to track (real) changes in SVN later on. It kind of destroys
the history.

List info: http://lists.roundcube.net/dev/

More information about the Dev mailing list