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