Sorry, I hit the wrong button. I am putting together a quick test here before I finish this email.
Brennan On Wed, 17 Jan 2007 21:19:39 -0600, Brennan Stehling <[EMAIL PROTECTED]> wrote: > > 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 <[EMAIL PROTECTED]> > 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 > -- > Brennan Stehling > Offwhite.net LLC > [EMAIL PROTECTED] -- Brennan Stehling Offwhite.net LLC [EMAIL PROTECTED]
