I agree with Brennan that a plugin system as he suggests will make
things a lot easier to create extensions. As it seems to be decided that
a RSS Reader would be considered a bloat, that part of the discussions
can now move elsewhere, and I will setup a devel page for it to be done
- if there are any volunteers!! :)
Back to the plugin discussion - what Brennan has suggested seems a lot
of work and a major change. As such the roadmap shows it as a 0.3
feature. That leaves me with several questions.
1. How are the discussions going along the speeding up the release
cycle, by focusing on the active tickets for each release?
2. How long does it seem before the plugin system could be implemented -
are we going to put it off for a while and concentrate on the core features?
3. Without a plugin system, how would we go about writing a plugin, such
as this RSS reader?
4. Should we set down some basic plugin guidelines or at least the
theory of the system so that we could start a project now, so that there
wouldn't be as much to change later?
Sam Bailey (cyprix)
Brennan Stehling wrote:
A while back I suggested breaking up the code to clearly separate the PHP,
Javascript and (X)HTML so that it would be much more flexible. A plugin system
would be a good example of that.
What I suggested was an HTML template system where the application loads
largely as static content which uses XHTML and CSS to draw each of the portions
of the page with class and id attributes carefully placed to denote important
areas, like the toolbar, folders and message box. From there Javascript would
use AJAX functions to communicate with the server. On the server PHP would
service the Javscript using the JSON protocol for a clean communication layer.
With this architecture you could create a very powerful plugin system. I would
have a Javascript library control all changes on the UI, such as loading
messages from the server and placing them into the message box. Consider when
the static template loads after you log into the system the following
Javascript would run:
function init() {
var rcc = new RoundCubeClient();
rcc.LoadFolders();
rcc.LoadMessages();
rcc.StartMonitor(); // polls server for new messages
}
In the LoadFolders and LoadMessages method they would run an AJAX request to
get the data necessary to call the following code...
rcc.AddFolder("Inbox");
rcc.AddFolder("Trash");
rcc.AddFolder("Junk");
rcc.AddFolder("Work");
And this RoundCubeClient object would be all static.
This leads into what you could do with a plugin architecture. A plugin could
do a good deal of work with just the Javascript and a little PHP on the
server. Modern Javascript techniques show how you can extend Javascript
objects with a little inheritance, so consider that a RoundCubeExtension object
could be defined as a base class which developers could use a base for
inheritance. They could override certain behavior, such as hooks which are
fired off by the RoundCubeClient. The client would loop over all configured
extensions and run their methods as appropriate. One method that a
SpamExtension may run is ProcessMessages() which may loop over all messages and
flag messages which match a certain criteria, like a X-Spam-Status header on
the message. The client would cal this method after the main method
ProcessMessages() on the default client is run.
On the server-side the PHP extensions could provide additional data and carry
out actions on the server. The Ajax requests can make any GET or POST requests
of the server. The SpamExtension may look at a message in the Inbox and see
the X-Spam-Status is set to Yes and call this function.
rcc.MoveMessage(message, "Junk");
Internally this MoveMessage function would carry out the same action that
happens when we drag a message from the Inbox to the Junk folder, but this
would happen with the extension.
The last time I looked the server-side PHP code was emitting a significant
amount of the Javascript and the HTML. If this sort of architecture looks
appealing I would like development to start moving in that direction as soon as
possible. We already have a lot of this all working, it just needs to be
pulled apart a bit into the distinct components.
When it comes to the RSS reader, the Javascript and JSON calls back to the
server do not need to know where the content comes from. We could just
implement a message type and allow plugins to handle messages by type. The PHP
code on the server has to emit the message in the required JSON format to
define the message id, subject, and body of the message. And dealing with
folders is another matter. The RSS reader could define folders which it
handles itself and when you click on them they are completely handled by the
extension.
This may sound pretty complex, but when each piece is built carefully it will
work quite well together and creating new features will be very easy.
Brennan
On Wed, 17 Jan 2007 18:33:37 +0100, Michael Bueker <[EMAIL PROTECTED]> wrote:
Sam Bailey wrote:
2. Create as a plugin or as a separate or joint project
According to the roadmap, a plugin API is in planning. I think an RSS
reading feature is beyond the scope of roundcube, and I personally would
consider it to be bloat.
But it seems a perfect model plugin, and many people will probably like
the functionality. Even if browser have RSS plugin, you don't usually
take your browser everywhere, but you do access roundcube from
everywhere. So it has its purpose.
Keep the 2 cents ;)
~Mik
--
I remember 20 years ago when young lady was just getting into email she
ask me if a virus could be spread by email. I just laughed and said no,
it would never happen. It would require that email readers have the
ability to execute code passed to them, and nobody would be stupid
enough to write a mail program that would do that.
- Lord Apathy on /.
