[RCD] Core Plugins

Ziba Scott ziba at umich.edu
Fri Mar 6 23:06:26 CET 2009

I've added the filesystem_attachments and database_attachments plugins
that I talked about earlier.  Along with them I added a bit of starter
code for core plugins

I added a list of plugins that are required for functioning to
rcube_plugin_api.php.  The init routine then checks to see if any loaded
plugin is of or extends that required plugin.  If it doesn't find one,
it will load the one it knows about.

So in this case, if you don't specify any attachment plugin, it will
load filesystem_attachments.  If you specify database_attachments, it
will recognize that database_attachments extends filesystem_attachments
and be happy.

This may be overly basic for now. There are some interesting routes we
could go down beyond just making inferences about plugins based on class
name (maybe special class properties or plugin ini files).

I just wanted to get something in place and working for the sake of the
attachment modules.  I'm happy to scrap that bit when something better
comes along.


Rick Romero wrote:
> On Fri, 2009-03-06 at 19:09 +0100, Thomas Bruederli wrote:
>> Ziba Scott wrote:
>>> I'm hoping we can obtain the best of both worlds (plugins and
>>> interfaces).  Perhaps by establishing that some plugins are "core" and
>>> will always exist, other plugins could safely inherit from them and
>>> implement related plugins without unnecessary duplication.
>> Good point. Using inheritance the application can make sure that at least 
>> one (ore maybe exactly one) plugin of a certain kind (class) is available.
>> After some more thinking about those core plugins, I'm not sure if the 
>> plugin approach works well for the address book. Since there can be several 
>> address sources (currently sql and ldap) together, it's not clear to me how 
>> plugin hooks can be implemented here. RoundCube maintains a list of objects 
>> that act as independet address sources and implement the same interface. Or 
>> do you think of habving a hook which creates all these objects?
> My .02 is that the hook to create the objects would be preferred.  With
> the horde plugin for example, you have firstname and lastname fields, as
> opposed to Roundcube's single 'name' field.  This is the most obvious
> issue when changing the backend.  Creating the objects on the fly could
> allow the user interface to be more dynamic to the needs to the hook
> backend.  
> Looking further down the road, it can also be used to further seperate
> the data layer from the presentation layer (beyond just skinning).
> Doing that can open up a wealth of completely different types of
> plugins  (Vacations, Forwards, Filters), with a hopefully 'not to
> difficult' implementation.
> Rick
>> ~Thomas
>>> Thomas Bruederli wrote:
>>>> Hi Ziba
>>>> What your propose sounds very interesting. I first intended to just
>>>> create interfaces (or abstract classes) for the addressbook and
>>>> file/cache access with the possibility to inject your own class by
>>>> config. But using the plugin-api could work well too and we certainly
>>>> don't need several mechanisms to provide similar functionality.
>>>> If you have some working code you could commit it to the devel-api
>>>> branch in order to let us all have a deeper look at this.
>>>> Regards,
>>>> Thomas
>>>> Ziba Scott wrote:
>>>>> Hi Roundcube Plugin API Devs,
>>>>> I wanted to float a concept out there for feedback: Core plugins.
>>>>> Hopefully I haven't missed a discussion about it elsewhere.
>>>>> A core plugin would be a plugin which is required for roundcube to
>>>>> function or must at least be replaced by a non-core plugin which serves
>>>>> the same function.  This is something Drupal has implemented with (in my
>>>>> opinion) great success.
>>>>> [...]
>> _______________________________________________
>> List info: http://lists.roundcube.net/dev/

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

More information about the Dev mailing list