The design of a plug-in system depends greatly on the design of the application (i.e. a PHP/AJAX plugin framework will, by necessity, look different from a C++/JavaScript framework), but there are plug-in concepts that we might consider from various applications. In my opinion, some of the considerations are:

• User Interface Extension - a plug-in should be allowed to add buttons or features to the user interface, and possibly customize or alter the existing user interface. The "theme" concept addresses some of this with a web application like RoundCube, but a plugin should probably be able to enhance or extend the user interface without having to write a whole theme
• Event Observation - the application should allow a plugin to register for and/or respond to different events (button clicks, page loads, etc.). The granularity of events again greatly depends on the application. For RoundCube, there probably need to be two kinds of event listeners - one within the JavaScript that runs on the user agent, and one within the server-side PHP.
• Versioning - this might be optional, but it's probably a good idea for the application to be able to verify at load-time whether a plugin is compatible with the current version of the application, or even better, the current version of the plugin framework within the application.
• Loading/Registration - the application should be able to discover and dynamically load plugins via some mechanism. This could be as easy as presence of a plug-in specific file or directory in a plugin directory with some well-known file/folder structure. Firefox/Mozilla uses a manifest system for the application to be able to discover some information about the plugin before registering it.
• State - plugins may want to be able to store persistent state or configuration information. We could just let plugins store files in their own directory tree, or give them access to the preferences structure in the database.

This is of course just general rambling, but if the solution accounts for all of these things I think we're in good shape...

-Eric

On Wed, 19 Jul 2006 10:31:18 +0200, Mark wrote:

phil wrote:
> On Mon, 17 Jul 2006 22:21:56 -0700, Florin Andrei  wrote:
>
>> Any Cyrus IMAPd users here? Please see this feature request:
>>
>> http://trac.roundcube.net/trac.cgi/ticket/1483889
>>
>> I'd say that the lack of the Sieve filter manager is the only thing that
>> prevents me from switching from Squirrelmail to Roundcube, even though
>> the latter is a better webmail.
>>
>
> it's definately needed, but still added functionality, so I'd wait until after this release, then put it at the top for the next.  In the meantime:
>
> http://smartsieve.sourceforge.net/
>
> we could migrate a chunk of that over for the 'filters' plugin for RC, which could be on a sep dev track than RC, and thus could get done quickly.
>
> Thoughts?
>
> P
>
>
>> --
>> Florin Andrei
>>
>> http://florin.myip.org/
>>
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
> --
> http://fak3r.com - you don't have to kick it
>
>
>
I believe we should be looking at places where we have to program hooks
in order to get a plugin system working. We might be surprised by the
plugins that start to pop up once that's finished.... but bottom line...
the plugin system is what needs to be before we can create things like
this.
    I'm trying to figure out the best way to do just that, but until now
I still didn't have the time to delve into every aspect I want to know
before starting on it. I was looking at squirrelmail as an example. Is
that a good example for a descent plugin system?

Mark