I also have a couple of servers and a Subversion repository. I the proof of concept just has to be something very simple to show how to technically pull off what I am suggesting.
We do not need to show that drag/drop would work since the current application already does that. What we need to implement is an event system which will fire before and after various actions.
The first test would be to add 3 blocks onto a static web page and wire it up with Javascript.
Block1 - larger gray block Block1 - small
Brennan
On Thu, 18 Jan 2007 11:35:46 +1100, Sam Bailey cyprix@cyprix.com.au wrote:
Brennan,
Fleshing out the proof of concept sounds like a good way to go with it. Specifically using JSON with event wrappers is a great idea as it keeps the flexibility required for a plugin API. How do we go about this?
Do you want to use the RSS Reader as the example for a proof of concept or just create a basic API etc?
A core + custom plugin arrangement is what I was thinking about in my original discussion, sort of an option 1 & 2. I can host the example/concept on my server if required.
Sam
Brennan Stehling wrote:
Sam,
I think application extensibility is absolutely important. The
applications which take off are the ones which can be customized to this degree. People love applications which can be extended because they are not limited and if they want a feature they usually can find it sooner or later. And if they really, really want it they could build it themselves.
To add plugin support to RC I would start documenting what a plugin
would be able to do from a functional standpoint. And I would consider how other applications have been built for extensibility. The main one that comes to mind is the Apache Web Server. Much of the functionality that people use is optional. But it is the most widely used web server because it can do so much. And if there is a shortcoming you can quickly overcome it by extending Apache with a module. Apache even allows extensions in different languages like Perl, PHP and Python so you start with C which few developers can do well but open up the extensibility to a very large pool of capable developers. By using JSON as the communications layer there is no reason the backend has to be PHP because JSON has been ported to all of the top programming languages.
For RoundCube I could see some of the existing features broken out into
plugins/extensions which come bundled with the installation with a few additional plugins disabled. The core plugins are excellent examples for those who choose to create a custom plugin. And as we add features to RC we make a more rich plugin architecture.
One important point is that the plugin developers who create custom
plugins are responsible for testing their own plugins with the RC releases. The core RC team will not be able to test every plugin and should not be expected to support them.
A feature I would want a plugin to be able to do is handle new messages
as they are coming in and when messages are moved between folders. From an event-driven standpoint I would like the event to be raised before the action is taken with the option to cancel it, and then again once the action has completed. For the folders, I would have these...
OnMessageMoving(source, cancelEventArgs) - before moving OnMessageMoved(source, eventArgs) - after moved
In each case the source would be the message which is moving and the
event args would have a property naming the sourceFolder and destinationFolder. And the cancelEventArgs.cancel property could be set to false to tell the caller not to move the message.
I think this would be a good construct for many of the plugin actions.
It is common with event-driven software.
I can easily think of a great way to use this as a plugin. I get emails
from my WordPress blog when people post comments with a very specific subject. If I want the comment on my blog deleted I could drag the email to the trash and the plugin would check if it is a blog comment message take the necessary action to delete the comment on my blog. And moving it to my Blog folder could mark a blog comment as approved. Instantly I could have RC integrated with WP. And if the plugin fails to authenticate with my WP blog it could cancel the move and show me a warning. This is something you clearly do not want in the RC core but would be beneficial to many users who also use WP.
That leads to the next point of extensibility. Some plugins will need
preferences set. So we would need a way for a plugin to display settings on the preferences screen.
I think we could gradually add more event wrappers to various parts of
the interface. With each RC release we can add new wrapper and the plugin developers can add handlers for each of the wrappers if they want to implement some behavior. But a plugin may just use one wrapper for a specific need. We just want to stabilize the initial wrappers so we do not keep changing how they work in later releases and break existing plugins.
Another use for a plugin would be for rendering messages. When I send
myself an invite from Google Calendar it sends along an .ics file. Outlook knows how to handle it which I think supported this feature first and Google copied it. I think Apple created the .ics format which MS copied. (wonderful integration!) I would like to use an invitation plugin which can detect this calendar data and do something to the display of the message to integrate with some sort of calendar system that the plugin provides.
For the address book, when I add a new contact a plugin could relay the
new contact to another system. A plugin could also handle lookups in a custom user store which we cannot predict for RC. LDAP integration is obvious, but if someone has a custom contact database they could create a plugin to integrate with it. And if one of the core plugins is an LDAP plugin they could use that as a starting point for their own plugin.
Sam,
What we can do is flesh out a proof of concept to present to the team.
Once we have put in the work to show a working demo it would be a few steps closer to seeing how it can be implemented with RC.
Brennan