[RCD] Core Plugins

Rick Romero rick at havokmon.com
Fri Mar 6 19:17:15 CET 2009


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