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.
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,
- framework-related changes to existing classes, e.g.
- get rid of $rcmail object usage in classes,
- can we exclude rcube_user class?
- make output/html/template classes optional,
- unify codestyle according to our CS ruleset
On Tue, Dec 27, 2011 at 09:17, A.L.E.C alec@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,
+1
- 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.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
Il giorno 27/dic/2011, alle ore 09:17, "A.L.E.C" alec@alec.pl ha scritto:
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.
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,
- framework-related changes to existing classes, e.g.
- get rid of $rcmail object usage in classes,
- can we exclude rcube_user class?
- make output/html/template classes optional,
- unify codestyle according to our CS ruleset
Hi Alec,
I'm working on roundcube source to add natively the multiple IMAP account support, and I created an abstraction class for rcube_imap. Beside that, I didn't want modify too much code, so I left many function calls as original, even that isn't the best option (I'm keeping my local SVN repo synced with roundcube trunk). I implemented successfully multiple account (IMAP and SMTP for now, I'm working to non-imap driver) and a simple authentication with LDAP. I'm using a simple DB table for login-to-account link.
I know that the goal of roundcube is to be a simple webmail, but what if we can support, for example, multiple accounts, centralized login, and more? We can leave to the sysadmin (who installs roundcube) the choice between a simple webmail and a more sophisticated webmail "application".
Beside that, I can help with roundcube development ;-)
PS: my code was written for maintain maximum compatibility with main roundcube development, so is very ugly because of many tricks and hack that are needed to avoid changing rouncube core code.
Enrico
List info: http://lists.roundcube.net/dev/ BT/aba52c80
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).
On 27.12.2011 19:13, Thomas Bruederli wrote:
- 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.
maybe, now would be a good time to switch to a different scm, git or hg for example.
in regard to the code history: using "git blame -w" ignores whitespaces when comparing the different revision to find where a particular line came from.
merging multiple lines into a single one (e.g. "if (...) {") might be another issue though.
cheers, raoul _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 27.12.2011 20:13, Enrico Bassetti wrote:
I'm working on roundcube source to add natively the multiple IMAP account support, and I created an abstraction class for rcube_imap. Beside that, I didn't want modify too much code, so I left many function calls as original, even that isn't the best option (I'm keeping my local SVN repo synced with roundcube trunk). I implemented successfully multiple account (IMAP and SMTP for now, I'm working to non-imap driver) and a simple authentication with LDAP. I'm using a simple DB table for login-to-account link.
I know that the goal of roundcube is to be a simple webmail, but what if we can support, for example, multiple accounts, centralized login, and more? We can leave to the sysadmin (who installs roundcube) the choice between a simple webmail and a more sophisticated webmail "application".
Beside that, I can help with roundcube development ;-)
Just share your code. As for the multi-account support, I think, it would be too much effort for now to do this well.
The work is in progress (devel-framework branch). I'll give you a current state information, so you can take over when I'll be on vacation next week.
Framework classes can be grouped in three groups:
- Roundcube Framework - Backend
rcube_addressbook rcube_cache rcube_config rcube_contacts rcube_imap rcube_imap_cache rcube_imap_generic rcube_ldap rcube_mdb2 rcube_mime rcube_plugin rcube_plugin_api rcube_result_* rcube_session rcube_smtp rcube_storage rcube_user rcube_spellchecker rcube_message
- depends on: rcmail, rcube_vcard, rcube_charset, rcube_shared.inc
- Roundcube Framework - Frontend
rcube_template rcube_json_output rcube_ui rcube_html_page
- depends on rcmail, backend + utils
- Roundcube Framework - Utils
html rcube_browser rcube_base_replacer rcube_string_replacer rcube_vcard rcube_charset
- depends on backend + utils
TODO:
- create rcube_framework class as a base for rcmail, which will contain
only backend-related functionality. The idea is that in use-case where UI is not needed we'll be able to just do: class rcmail extends rcube_framework {}
- make plugins api optional, create rcmail::exec_hook() as
plugins->exec_hook() wrapper,
- don't use translation (gettext()) inside backend classes, e.g. should
rcube_addressbook return translated error messages? I think so.
- should rcube_message go to the backend group? if so, it cannot depend
on rcube_ui nor localization,
- fix html class dependencies (rcube_ui::Q) so it can be "moved" to
Utils group,
- review dependencies and make so classes from Utils group depend only
on rcube_shared.inc or even nothing,
- fix rcube_message class dependencies (rcube_ui, localization) and/or
move it to Frontend,
- don't use function aliases from main.inc file, rename it to
rcube_bc.inc and don't include it by default. Leave it for lazy plugin authors (or add an option in config to do that without any code changes).
- review RCMAIL_CHARSET constant usage
On Wed, Dec 28, 2011 at 6:36 AM, Raoul Bhatia [IPAX] r.bhatia@ipax.at wrote:
On 27.12.2011 19:13, Thomas Bruederli wrote:
- 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.
maybe, now would be a good time to switch to a different scm, git or hg for example.
+1 for git on github :)
On 27.01.2012 12:34, A.L.E.C wrote:
Framework classes can be grouped in three groups:
And one issue related to this division: rcube_plugin class depends on rcube_output - would be good to remove this dependency.
On 27.01.2012 12:53, Reinaldo de Carvalho wrote:
On Wed, Dec 28, 2011 at 6:36 AM, Raoul Bhatia [IPAX]r.bhatia@ipax.at wrote:
On 27.12.2011 19:13, Thomas Bruederli wrote:
- 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.
maybe, now would be a good time to switch to a different scm, git or hg for example.
+1 for git on github :)
though i'm (most of the time) a very happy mercurial user, i very much enjoy githubs features - so +1 for github too...
cheers, raoul _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 27.01.2012 12:34, A.L.E.C wrote:
TODO:
- create rcube_framework class as a base for rcmail, which will contain
only backend-related functionality. The idea is that in use-case where UI is not needed we'll be able to just do: class rcmail extends rcube_framework {}
- make plugins api optional, create rcmail::exec_hook() as
plugins->exec_hook() wrapper,
- don't use translation (gettext()) inside backend classes, e.g. should
rcube_addressbook return translated error messages? I think so.
- should rcube_message go to the backend group? if so, it cannot depend
on rcube_ui nor localization,
any comments on the above points?
- fix html class dependencies (rcube_ui::Q) so it can be "moved" to
Utils group,
done.
Some more ideas:
- create rcube_input utility class for get_input_value() related
functionality,
- create abstract rcube_output class (with some output-related utilities
e.g. json_serialize())
- rename rcube_json_output to rcube_output_json, it should extend
rcube_output
- rename rcube_html_page to rcube_output_html, it should extend rcube_output
- rename rcube_template to rcube_output_html_template
On Mon, Feb 6, 2012 at 15:53, A.L.E.C alec@alec.pl wrote:
On 27.01.2012 12:34, A.L.E.C wrote:
TODO:
- create rcube_framework class as a base for rcmail, which will contain
only backend-related functionality. The idea is that in use-case where UI is not needed we'll be able to just do: class rcmail extends rcube_framework {}
- make plugins api optional, create rcmail::exec_hook() as
plugins->exec_hook() wrapper,
- don't use translation (gettext()) inside backend classes, e.g. should
rcube_addressbook return translated error messages? I think so.
- should rcube_message go to the backend group? if so, it cannot depend
on rcube_ui nor localization,
any comments on the above points?
I general, yes. The rcube_message class is our interpretation of a mime message and should be pretty general. I don't see where rcube_ui comes into the game here and we hopefully can find a way to replace the rcube_label() calls with some placeholders which can then be localized by the app itself.
Some more ideas:
- create rcube_input utility class for get_input_value() related
functionality,
If this is the only function, we should rather move it to a utils class.
- create abstract rcube_output class (with some output-related utilities
e.g. json_serialize())
+1
- rename rcube_json_output to rcube_output_json, it should extend
rcube_output
- rename rcube_html_page to rcube_output_html, it should extend rcube_output
The less renaming the better...
- rename rcube_template to rcube_output_html_template
Since rcube_template is the only class extending rcube_html_page, we could actually merge them together and just name 'rcube_output_html' or 'rcube_html_output'.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Mon, Feb 6, 2012 at 15:53, A.L.E.C alec@alec.pl wrote:
On 27.01.2012 12:34, A.L.E.C wrote:
TODO:
- create rcube_framework class as a base for rcmail, which will contain
only backend-related functionality. The idea is that in use-case where UI is not needed we'll be able to just do: class rcmail extends rcube_framework {}
- make plugins api optional, create rcmail::exec_hook() as
plugins->exec_hook() wrapper,
I don't have a clear picture how the plugin API can fit into this split of classes. It's clear that some framework classes need to trigger plugin hooks directly. Therefore we cannot just keep the plugin API in the app part. On the other hand I actually don't like the idea of rcmail (which to me represents "the app") being derived from a rcube_framework class.
What about making rcube_plugin_api a framework class with a singleton getter and for convenience reasons add some static methods such as rcube_plugin_api::exec_hook(). And the actual loading of the plugins is then initiated by the app (e.g. rcmail::startup()) and no longer integrated part of rcube_plugin_api::init(). That way the app (rcmail) can load the plugins according to the local config and only those matching the current task and the framework classes can still trigger plugin hooks without requiring direct context of rcmail. Furthermore a user of the framework can also create/use plugins and load them into the rcube_plugin_api singleton in his very own app and according to his very own configuration and criterias.
- don't use translation (gettext()) inside backend classes, e.g. should
rcube_addressbook return translated error messages? I think so.
rcube_addressbook doesn't necessarily need to return translated messages, we already have some abstraction with the constants ERROR_* in that class. However, I don't think that rcube_addressbook (and derived classes) should become part of the framework. Format and wrapper classes such as rcube_ldap_generic (being a generic ldap wrapper without specific address book functions) as well as rcube_vcard are good candidates for the framework and should be decoupled as much as possible. The entire address book classes are part of the application and probably not very useful to anybody else.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
-
A.L.E.C -
Enrico Bassetti -
Raoul Bhatia [IPAX] -
Reinaldo de Carvalho -
Thomas Bruederli