Hi guys, good job Brennan & Till

Sounds well thought out and interesting. Never heard of a JSON-only plugin API. What about sharing of resources, libraries and such. And have you thought about in what way an API would be limited... would it have it's own dir to write files and such ?

wii Arnor

On 2/6/07, till klimpong@gmail.com wrote:

Hi boys and girls,

the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft

Happy to read all your feedback!

Cheers, Brennan & Till

-- Till Klampaeckel e: mailto:klimpong@gmail.com p: +491704018676 l: http://beta.plazes.com/whereis/till

Want to know what's up in Berlin?

• http://berlin.metblogs.com

The concept is to have 3 trays as constant.

The trays for Controls, Folders, Messages

The client-side API will provide an object oriented layer to manage the trays. Some objects in this system will be Buttons, Folders, Messages among others. I am also now thinking there will be an ErrorTray. Each of these trays will have inherent behavior just as they already do, but the Javascript objects will take care of them. It will be cleanly encapsulated.

For example, the example adds buttons as RoundCube.Button objects to an Array of buttons in the ControlsTray object. The updateTray method on the ControlsTray object actually renders the buttons to the tray as HTML elements.

The display will be controlled by static HTML constructs with CSS and graphics while the Javascript simply changes elements within that construct. At any time the HTML templates and CSS could be adjusted for color or size without impacting the Javascript which only cares that it will be adding an element to a tray.

The RoundCube.Application object will be the main controller of the application. It will use all of the other RC objects which will encapsulate their individual behavior, data and manage their relationships. For example, the ControlsTray holds a collection of Buttons. The FolderTray will hold a collection of Folder objects and the MessageTray will hold a collection of Message objects. The Application object holds all of them. Those are the relationships they will maintain. Each tray will have an updateTray method which will clear and repopulate the tray using the objects it holds in memory.

Next there will be events which fire for a set of defined points, such as when a Message is dropped onto a Folder. That will fire the MessageDropping and MessageDropped events. The core functionality for the IMAP side of RC will do what it does now and generate a request to the server to move the message to the new IMAP folder. If there is a failure or the server refuses the request after the MessageDropping event happens it will send message to the ErrorTray and not fire the MessageDropped event. When the MessageDropped event does happen it will carry out the action and remove the Message object from the source Folder object and place it in the destination Folder and the FolderTray and MessageTray will both be updated to reflect the change visually, such as changing the count on the affected folders and removing the Message from the MessageTray.

The sequence is to request the action and then once it the action is accepted it will commit the action for the display. At any of the points where events are fired something can happen but the details are not planned out yet.

When the MessageTray is updated a plugin could can the Message objects which hold all of the mail headers for SpamAssassin headers and mark the spam messages and also add a button to the ControlTray to move all spam messages from the Inbox Folder to the Junk Folder.

We are still in the very early stages. The plan is to just start building the static HTML and CSS files from the existing dynamically generated content so that it looks exactly the same. Then we will instrument the markup to ensure it is structured to workw with this tray concept and then start building an object representation of the UI which draws everything.

As we go we will be defining various JSON messages but it does appear the collection of generic instructions could do a good deal of the heavy lifting. The processInstructions method on the Application object could do a lot of the work.

As for plugins, they will exist as part PHP and part Javascript with their associated CSS and image files. The Javascript plugins will extend from a base class called RoundCube.Plugins.BasePlugin which will add some core facilities for all plugins like error handling and interactions with each of the trays. The client-side Javascript can make requests through JSON messages to the server-side PHP code to carry out an action. That is all up in the air and I am anxious to see what people implement once we have a system ready for third-party extensions.

Till and I have discussed that the existing IMAP features will be plugins as well, just as with the Apache web server everything is a module. There are core modules and third-party modules. The core modules for RC will be a good reference for third-part developers. And it will help Till and I work out issues to support a rich IMAP system so that those same features will be available for the third-party plugins.

There is much more to plan out. I am interested in any involvement and support you all can offer.

Brennan

On 2/6/07, Arnór Heiðar arnorhs@gmail.com wrote:

Hi guys, good job Brennan & Till

Sounds well thought out and interesting. Never heard of a JSON-only plugin API. What about sharing of resources, libraries and such. And have you thought about in what way an API would be limited... would it have it's own dir to write files and such ?

wii Arnor

On 2/6/07, till klimpong@gmail.com wrote:

...

Hi boys and girls,

the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft

Happy to read all your feedback!

Cheers, Brennan & Till

-- Till Klampaeckel e: mailto:klimpong@gmail.com p: +491704018676 l: http://beta.plazes.com/whereis/till

Want to know what's up in Berlin?

• http://berlin.metblogs.com