Dear Developers!
I am using RC in my hosting offers and I want to implement two things:
- a kind of plugin-mechanism: It should be possible to "register" some
external plugins to events (User login, handling contact data, ...)
- a Funambol-Plugin (as seperate open source project): Funambol is a server
capable of syncing contacts/calendar items between native Clients (Outlook, Thunderbird), various Devices (many mobile phones, PDA's, ...) and other webmail-applications and groupwares.
I talked to A.L.E.C. some days ago because he had plans for the plugin infrastructure. According to his mails he has no time to develop this in the near future and I asked him if I can do the work. He answered it would be ok, so I'll ask you how it should be done:
So here are my questions:
- How should a plugin-architecture be implemented in RoundCube?
Maybe my approach is completely wrong, just tell me if you think so... I'm thinking of a PluginHooks singleton class which is called from various points in the existing source code. This class reads a config file if there is a plugin registered for the specific event. This config contains a line for each event like this: $rcmail_config['pluginevent_userlogin'] = array('Funambol'); //registers a single plugin called "funambol" for the event "userlogin" $rcmail_config['pluginevent_nextEvent'] = array('Funambol', 'AnotherPlugin); //call two plugins in the given order PluginHooks then initates a class Funambol (located in RC_Home/plugins/Funambol) and calls a method pluginevent_userlogin. Because PluginHooks is a singleton, it could provide methods to the plugins to get or manipulate data from the rest of RC. so anything is handled over this class. I hope I discribed it well. Please bring your own ideas if you have better once.
Is anyone interested in teaming up?
Is anyone willing to implement plugins in near future? If so - please talk
to me to discuss your requirements to make this project as useful as possible.
You can send me a CC so I can answer your mails quicker.
Thanks in advance, Greetings
Florian Lagg wrote:
So here are my questions:
- How should a plugin-architecture be implemented in RoundCube?
Maybe my approach is completely wrong, just tell me if you think so... I'm thinking of a PluginHooks singleton class which is called from various points in the existing source code. This class reads a config file if there is a plugin registered for the specific event. This config contains a line for each event like this: $rcmail_config['pluginevent_userlogin'] = array('Funambol'); //registers a single plugin called "funambol" for the event "userlogin" $rcmail_config['pluginevent_nextEvent'] = array('Funambol', 'AnotherPlugin); //call two plugins in the given order PluginHooks then initates a class Funambol (located in RC_Home/plugins/Funambol) and calls a method pluginevent_userlogin. Because PluginHooks is a singleton, it could provide methods to the plugins to get or manipulate data from the rest of RC. so anything is handled over this class. I hope I discribed it well. Please bring your own ideas if you have better once.
Hi Florian, first of all thanks for the offer to do a lot of work for the community!
Regarding the config as you outline it above - I don't think this is the way to go as it is not very flexible; ideally a plugin just requires to be downloaded to a certain directory and to be enabled in a single place, that's it. In the above code every time a plugin is added the config has to be changed to adopt the hooks.
Instead I would recommend a well-known location (index.php, config.php) in the plugins directory which calls those hook-registration points itself. This gives full control over to the plugin with minimal impact on configuration.
My 2 cents,
Mike
Regarding the config as you outline it above - I don't think this is the way to go as it is not very flexible; ideally a plugin just requires to be downloaded to a certain directory and to be enabled in a single place, that's it. In the above code every time a plugin is added the config has to be changed to adopt the hooks.
Instead I would recommend a well-known location (index.php, config.php) in the plugins directory which calls those hook-registration points itself. This gives full control over to the plugin with minimal impact on configuration.
You're right - we do not need an extra configuration.
Plugins are placed in RC_home/plugins/PluginName/PluginName.php and contains "class PluginName extends PluginAbstract" Each time any event is raised we initialize every plugin class and try to call the corresponding function in the plugin. This way we do not need any configuration.
Is this your intention?
List info: http://lists.roundcube.net/dev/
Florian Lagg wrote:
Instead I would recommend a well-known location (index.php, config.php) in the plugins directory which calls those hook-registration points itself. This gives full control over to the plugin with minimal impact on configuration.
You're right - we do not need an extra configuration.
Plugins are placed in RC_home/plugins/PluginName/PluginName.php and contains "class PluginName extends PluginAbstract" Each time any event is raised we initialize every plugin class and try to call the corresponding function in the plugin. This way we do not need any configuration.
Did I miss some conversation here?
Please also regard the recent conversation about plugin architecture: http://lists.roundcube.net/mail-archive/dev/2008-06/0000023.html http://lists.roundcube.net/mail-archive/dev/2008-06/0000038.html
Also initializing all plugins on every event is bad for performance. I'd suggest to have a plugin-controller which is created once and which loads all plugins with their hooks. Every time a plugin-hook is triggered, the controller will pass the event to all plugins that registered this hook.
Forian, do you plan to implement the whole plugin-architecture of RoundCube or are you just talking about your Funabol integration?
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Florian Lagg wrote:
Plugins are placed in RC_home/plugins/PluginName/PluginName.php and contains "class PluginName extends PluginAbstract" Each time any event is raised we initialize every plugin class and try to call the corresponding function in the plugin. This way we do not need any configuration.
Is this your intention?
I would not initialize the plugin on each hook, but instead initialize all plugins once. Also if you are using an abstract class you don't need to configure hooks, the class is just not overriding functions which perform valid defaults (=nothing).
Other option are static functions, but this is less flexible.
Mike
Did I miss some conversation here?
No, we just started.
Please also regard the recent conversation about plugin architecture: http://lists.roundcube.net/mail-archive/dev/2008-06/0000023.html http://lists.roundcube.net/mail-archive/dev/2008-06/0000038.html
Thanks for that links. I had no details about earlier plans. I will have a look at it.
Also initializing all plugins on every event is bad for performance. I'd suggest to have a plugin-controller which is created once and which loads all plugins with their hooks. Every time a plugin-hook is triggered, the controller will pass the event to all plugins that registered this hook.
catched it. That's the reason why we 're discussing here. If I understand A.L.E.C.'s Ideas right:
- Each plugin has an init.php which registers to events:
/myplugin/init.php: init_plugin('init', 'functionname'); init_plugin('showmail', 'functionname');
- the Controller does a loop over the plugin/subdirectories to get these
registries
- this is somewhat like an decentralized configuration seperated over the
plugin directories.
Forian, do you plan to implement the whole plugin-architecture of RoundCube or are you just talking about your Funabol integration?
I prefer this approach:
- I plan to build a generic plugin-architecture. I will not code any aspect
of a full featured "plugin-architecture" but only the needed parts for now - but i want to make it as much extendible as possible to support any possible kind of plugin later.
- Together with the plugin-architecture I want to implement an Demo-Plugin
as a reference. The Funambol plugin just has too much Funambol-logic in it so it wouldn't be a good start for a new plugin.
- Then I will extend the Demo-Plugin to my Funambol-Plugin.
I think it does not make sence to implement a full featured plugin monster if we do not need it right now. But we should be able to extend it to a monster if we need to do so later ;-)
List info: http://lists.roundcube.net/dev/
Florian Lagg wrote:
If I understand A.L.E.C.'s Ideas right:
- Each plugin has an init.php which registers to events:
/myplugin/init.php: init_plugin('init', 'functionname'); init_plugin('showmail', 'functionname');
Yes, but I'd prefer an object-oriented approach: http://lists.roundcube.net/mail-archive/dev/2008-06/0000038.html
- the Controller does a loop over the plugin/subdirectories to get these
registries
Right. This procedure could even be cached for performance reasons.
I think it does not make sence to implement a full featured plugin monster if we do not need it right now. But we should be able to extend it to a monster if we need to do so later
Exactly!
~Thomas
List info: http://lists.roundcube.net/dev/
I agree Mike a single location is what I would say is a solid solution. To simplify for beginners a simple editing script could be made to assist when adding a plugin to config the hooks. Talk about a solid plugin architecture was brought up in recent discussion and I have been seeing more and more about this so I would say maybe it is time implement more solid plugin functionality.
Pat
On 7/31/08, Michael Baierl mail@mbaierl.com wrote:
Florian Lagg wrote:
So here are my questions:
- How should a plugin-architecture be implemented in RoundCube?
Maybe my approach is completely wrong, just tell me if you think so... I'm thinking of a PluginHooks singleton class which is called from various points in the existing source code. This class reads a config file if there is a plugin registered for the specific event. This config contains a line for each event like this: $rcmail_config['pluginevent_userlogin'] = array('Funambol'); //registers a single plugin called "funambol" for the event "userlogin" $rcmail_config['pluginevent_nextEvent'] = array('Funambol', 'AnotherPlugin); //call two plugins in the given order PluginHooks then initates a class Funambol (located in RC_Home/plugins/Funambol) and calls a method pluginevent_userlogin. Because PluginHooks is a singleton, it could provide methods to the plugins to get or manipulate data from the rest of RC. so anything is handled over this class. I hope I discribed it well. Please bring your own ideas if you have better once.
Hi Florian, first of all thanks for the offer to do a lot of work for the community!
Regarding the config as you outline it above - I don't think this is the way to go as it is not very flexible; ideally a plugin just requires to be downloaded to a certain directory and to be enabled in a single place, that's it. In the above code every time a plugin is added the config has to be changed to adopt the hooks.
Instead I would recommend a well-known location (index.php, config.php) in the plugins directory which calls those hook-registration points itself. This gives full control over to the plugin with minimal impact on configuration.
My 2 cents,
Mike
-- Michael Baierl http://mbaierl.com/blog/ < Mike's Blog
Java is renowned for its industry-standard visual interface which supports up to 16 colors thanks to its cutting-edge SmartColor™ technology./n _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Hi,
thanks for your comment. The Information you rely on is a fairly old.
Currently I have plans implementing it this way (OVERVIEW):
- There's a directory with plugins, e.g. ./plugins/*
- Each plugin resides in a own directory, let's call it "foo_plugin" for
now. This assumes that there is a file called foo_plugin.inc which includes a class foo_plugin
- In the configuration, we have a simple array list of enabled plugins
$rcmail_config['plugins_enabled'] = array('foo_plugin', 'bar_plugin');
- on the first called hook we initiate the rcube_plugins class which is a
singleton this class initalizes every plugin and - in the constructor of these - the plugins itself register to some hooks. this is done only once every request (because rcube_plugins is a singleton)
- if registered hooks are called...
every plugin is called - one after another - in the order given in the config above. therefore an array of data is passed to each plugin - and at last - returned to the roundcube code.
Have I missed someting?
I don't exactly know if this process was posted before completely - but this is what I am thinking about currently. Thanks for anyone contributed so far.
I 've set mysqlf a deadline to wait for requests before implementing a second prototype. This is the 19th of August. From that date on I want to implement a second prototype using the current definition over the following weekend.
Theoretically it should be functional and ready for testing.
I try to keep track of the current discussion in summary here: http://www.lagg.at/temp/todo-rc-plugin There are also some open questions (mostly regarding implementing frontend plugins) on this site.
Thanks,
Von: Patrick Garsow [mailto:pgarsow@gmail.com] Gesendet: Donnerstag, 7. August 2008 21:48 An: Michael Baierl Cc: Florian Lagg; RoundCube Dev Betreff: Re: [RCD] Plugin-Architecture I agree Mike a single location is what I would say is a solid solution. To simplify for beginners a simple editing script could be made to assist when adding a plugin to config the hooks. Talk about a solid plugin architecture was brought up in recent discussion and I have been seeing more and more about this so I would say maybe it is time implement more solid plugin functionality. Pat On 7/31/08, Michael Baierl mail@mbaierl.com wrote: Florian Lagg wrote: > So here are my questions: > * How should a plugin-architecture be implemented in RoundCube? > Maybe my approach is completely wrong, just tell me if you think so... > I'm thinking of a PluginHooks singleton class which is called from > various points in the existing source code. This class reads a config > file if there is a plugin registered for the specific event. This config > contains a line for each event like this: > $rcmail_config['pluginevent_userlogin'] = > array('Funambol'); //registers a single > plugin called "funambol" for the event "userlogin" > $rcmail_config['pluginevent_nextEvent'] = array('Funambol', > 'AnotherPlugin); //call two plugins in the given order > PluginHooks then initates a class Funambol (located in > RC_Home/plugins/Funambol) and calls a method pluginevent_userlogin. > Because PluginHooks is a singleton, it could provide methods to the > plugins to get or manipulate data from the rest of RC. so anything is > handled over this class. > I hope I discribed it well. Please bring your own ideas if you have > better once. Hi Florian, first of all thanks for the offer to do a lot of work for the community! Regarding the config as you outline it above - I don't think this is the way to go as it is not very flexible; ideally a plugin just requires to be downloaded to a certain directory and to be enabled in a single place, that's it. In the above code every time a plugin is added the config has to be changed to adopt the hooks. Instead I would recommend a well-known location (index.php, config.php) in the plugins directory which calls those hook-registration points itself. This gives full control over to the plugin with minimal impact on configuration. My 2 cents, Mike -- Michael Baierl http://mbaierl.com/blog/ < Mike's Blog - - - - - - - - - - - - - - - - - - - - - Java is renowned for its industry-standard visual interface which supports up to 16 colors thanks to its cutting-edge SmartColor technology./n _______________________________________________ List info: http://lists.roundcube.net/dev/ _______________________________________________ List info: http://lists.roundcube.net/dev/
-
Florian Lagg -
Michael Baierl -
Patrick Garsow -
Thomas Bruederli