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?
~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/