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.
I believe there would be several benefits to implementing some core, required elements of roundcube using the plugin api:
- The plugin api is assured to become potent and robust as it's heavily
depended on
- There almost no learning gap between developing/maintaining a plugin
and a core feature.
- This would eliminate the need for code which reads: "check for a plugin to do this, otherwise do it the regular way"
- The non-plugin code base becomes smaller and more focused
I'm not proposing there be a concerted effort to re-factor everything as plugins but making some core plugins could open doors.
In a test branch we plugin-ized a few core things and liked what we saw:
IMAP Caching: We replaced all the imap caching calls with plugin hook calls. Then it was easy to implement memcache caching instead of sql caching.
Temporary File Handling: We replaced all the read/write attachments to disk calls with plugin calls and wrote two plugins: Filesystem, to handle attachments just as before and Database to handle attachments in a multi-server friendly way. Memcache would be another option.
Contacts: We added a few hooks, re-factored rcube_contacts.php and rcube_ldap.php into plugins, and then made a horde contacts plugin.
What do you all think?
Thanks, Ziba _______________________________________________ List info: http://lists.roundcube.net/dev/
On Tue, 2009-03-03 at 17:39 -0500, Ziba Scott wrote:
Hi Roundcube Plugin API Devs,
Contacts: We added a few hooks, re-factored rcube_contacts.php and rcube_ldap.php into plugins, and then made a horde contacts plugin.
I was just going to ask how I should go about making the addressbook code 'generic' so it could share contacts with Horde. In the past I had changed the actual selects, but was thinking about making the fields variables in rcube_contacts.php, and mapping them to entries in db.inc.php. A Real Pluginsounds like a much better way to go. 'Regular' users wouldn't need to alter anything, and anyone else can use whatever backend they like.
memcache is also something I was considering. Do you have any patches to share? :)
Thanks, Rick
What do you all think?
Thanks, Ziba _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Ziba Scott wrote:
- The plugin api is assured to become potent and robust as it's heavily
depended on
- There almost no learning gap between developing/maintaining a plugin
and a core feature.
- This would eliminate the need for code which reads: "check for a plugin to do this, otherwise do it the regular way"
- The non-plugin code base becomes smaller and more focused
I'm not proposing there be a concerted effort to re-factor everything as plugins but making some core plugins could open doors.
I think it's a good idea and proposed core plugins sounds reasonable.
Hello Ziba,
We are also working on the API branch.
What you propose is very interesting. This hits exactly where we have been looking at doing some modifications, ie the Contacts / Address book.
We are also working on the jQuery side of things.
Would it be possible to get a copy of what you are working on? If we could combine efforts in some ways, it might get lots more done, quicker. Being able to take a look at your 'plugin-ized' core could be a great start.
We are going to be posting more patches soon.
Regards
Chris
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.
I believe there would be several benefits to implementing some core, required elements of roundcube using the plugin api:
- The plugin api is assured to become potent and robust as it's heavily
depended on
- There almost no learning gap between developing/maintaining a plugin
and a core feature.
- This would eliminate the need for code which reads: "check for a plugin to do this, otherwise do it the regular way"
- The non-plugin code base becomes smaller and more focused
I'm not proposing there be a concerted effort to re-factor everything as plugins but making some core plugins could open doors.
In a test branch we plugin-ized a few core things and liked what we saw:
IMAP Caching: We replaced all the imap caching calls with plugin hook calls. Then it was easy to implement memcache caching instead of sql caching.
Temporary File Handling: We replaced all the read/write attachments to disk calls with plugin calls and wrote two plugins: Filesystem, to handle attachments just as before and Database to handle attachments in a multi-server friendly way. Memcache would be another option.
Contacts: We added a few hooks, re-factored rcube_contacts.php and rcube_ldap.php into plugins, and then made a horde contacts plugin.
What do you all think?
Thanks, Ziba _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Great idea!
Ziba Scott, 09.03.03 23:39:
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.
I believe there would be several benefits to implementing some core, required elements of roundcube using the plugin api:
- The plugin api is assured to become potent and robust as it's heavily
depended on
- There almost no learning gap between developing/maintaining a plugin
and a core feature.
- This would eliminate the need for code which reads: "check for a plugin to do this, otherwise do it the regular way"
- The non-plugin code base becomes smaller and more focused
I'm not proposing there be a concerted effort to re-factor everything as plugins but making some core plugins could open doors.
In a test branch we plugin-ized a few core things and liked what we saw:
IMAP Caching: We replaced all the imap caching calls with plugin hook calls. Then it was easy to implement memcache caching instead of sql caching.
Temporary File Handling: We replaced all the read/write attachments to disk calls with plugin calls and wrote two plugins: Filesystem, to handle attachments just as before and Database to handle attachments in a multi-server friendly way. Memcache would be another option.
Contacts: We added a few hooks, re-factored rcube_contacts.php and rcube_ldap.php into plugins, and then made a horde contacts plugin.
What do you all think?
Thanks, Ziba _______________________________________________ List info: http://lists.roundcube.net/dev/
On Tue, Mar 3, 2009 at 11:39 PM, Ziba Scott ziba@umich.edu wrote:
(...) What do you all think?
Really good stuff, thanks for moving this forward.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
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/
Hi Thomas,
I will certainly commit code as I cleanup/merge the 6 or so branches I've made for experiments.
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.
Cheers, Ziba
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/
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/
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/
Hi, 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.
Regards, Ziba
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/
-
A.L.E.C -
Balazs Horvath -
Chris Moules -
Rick Romero -
Thomas Bruederli -
till -
Ziba Scott