On Mon, Jun 9, 2008 at 2:21 PM, Michael Baierl <[EMAIL PROTECTED]> 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/
