On Mon, Jun 9, 2008 at 2:21 PM, Michael Baierl mail@mbaierl.com wrote:
till wrote:
Maybe we can work on a required set of "methods" and calls for all plugins to get rid off those [file, function]_exists() things. We
Still you need them as RCD should not fail in case something is missing. And it does not make sense to force the plugin developer to have to create a long template with all callbacks. You will always end up with such _exists() methods if you upgrade your Plugin API - you don't want the plugins to fail...
I don't see why we cannot demand plugins to come with a clean api. I am not talking about 30 methods, more like 4 or 5 that have to be there. And if they are empty, I am personally willing to waste those extra bytes. ;-)
In the end, we'll have to support all that stuff people come up with. We should plan on enforcing relatively strict guidelines on plugins. Not to offend anyone, but most projects don't do this and you end up with a large repository but the quality of the majority of the components is poor, they won't work after an major PHP upgrade, have no documentation, are not updated in case of a bug/exploit and so on.
So, I'd rather 10 plugins that are well done, then 30 which are not. :-)
could also register available methods/calls via an ini file (of course parsing of those should be cached) which exposes them.
Why INI? Use a PHP file instead. And still it will be slower then using function names and function_exists calls.
Why not? It's relatively clean, doesn't require deeper code knowledge to edit ("Why do I need to escape this string inside this definition?"). The trade-off here is speed, of course. Still, the parsing can be cached.
I am all for dropping in plugins and running them - on the same side this very dynamic context also eats away on resources, so maybe we should have a plugin.ini after all which initializes them or lets roundcube know what is available.
I've already coded some plugin system and did not see any performance hit. I know Typo3 and know that it can eat up a lot of memory in case of a lot of extensions are loaded, but still the plugin overhead itself is relatively small. If you care about file_stat calls (_exists) - just use one init.php per plugin which then loads all other required files.
Maybe you are right, but we already have lots of issues with memory_limit and so on. Yeah, we do have some issues with composing and parsing and the way the libs we use handle objects and (not) worry about their memory footprint. Yet, people also complain that RoundCube won't run with 12 MB RAM, etc.. I can see the next discussion.
I am sure that even the dynamic context [could, should] be cached as well. I just don't want RoundCube to take 20 secs to pull up a login form. ;-) In the end, imap is already not the fastest kid on the block.
Personally, I like to have things expicit - configuring things requires that you go into a config file at least once and enable it, and you have to go in to disable it. We could also extend that some time with an interface for the postmaster@ account (just brainstorming here ;-)).
Cheers, Till _______________________________________________ List info: http://lists.roundcube.net/dev/