Hey Everyone,
I was thinking that an rss reader could be integrated into RoundCube. Whether this would better be added as a plugin or integrated directly I'm not sure. And again whether to build our own or use an existing system.
To my understanding there are four options: 1. Create a branch and integrate into RoundCube [my preference - see below] 2. Create as a plugin or as a separate or joint project 3. Grab an existing project and modify as either plugin or direct integration 4. Forget about it and use other systems for rss
If we choose option 1, then I'd like to help manage the overall development of the rss system, as well as doing some coding. However my skills are probably not up to doing this on my own. It may be necessary to separate the development as it is a significant project, and have it's own dev list [it's just a little bigger than the address book rewrite]. I think that integration is better than a plugin though due to the size of the exercise.
If option 2, then obviously we need to get this discussion off this list and move it elsewhere. I am willing to host a development forum/wiki/test server for this, and help manage it as a separate project. An RSS Reader may be too big to be just a plugin and so development as a joint project may possibly be a good idea.
If option 3, then as for option 2, however my involvement may be limited to consultation.
If option 4, well you get the idea :(
I believe that RoundCube would be seen as a better solution [it already is ;)] with an RSS reader. It would allow you to have that remote access to your feeds along with your email (again see Thunderbird), saving time and making the whole experience a bit better.
As a webmail project, my understanding is that RoundCube does not want or need to be the all encompassing solution. However I think that an RSS reader would be a welcome addition, and should not be seen going as or pushing the project down the groupware path.
All comments or thoughts on this are welcome and encouraged. :)
I figured it would be something like this:
- Integrated into the email page [my preference]
+ Feed list where the folders currently sit (i.e.
Thunderbird)
+ maybe as a separate pane underneath like the preview pane
+ ability to hide email folders and show feeds
+ option to have multiple feeds come into one folder
+ Actual feed showing in the email list section
+ sort by seen status
+ Web page displayed in preview pane or new window
+ able to select either:
* full page
* full page without images
* summary
* etc.
+ Feed list stored in database along with entries from each feed
+ save seen/unseen status
+ Folder list
+ "drag and drop" feed links to creatable folders for future
reference etc.
+ Forward feed link via email
+ opens new email with set text & hyperlink
+ Digg/del.icio.us/etc. this link function
+ added extras services via config
+ Feed & folders searchable
- OR have a separate page altogether based on the email page
Thanks
Sam Bailey (cyprix)
Cyprix Enterprises www.cyprix.com.au Melbourne, Australia
Planet Cyprix Blog blog.cyprix.com.au
Don't most browsers already have an RSS reader?
Personally, I'm most interested in using roundcube as an email client. Maybe we need a plugin infrastructure?
Matt
Sam Bailey wrote:
Hey Everyone,
I was thinking that an rss reader could be integrated into RoundCube. Whether this would better be added as a plugin or integrated directly I'm not sure. And again whether to build our own or use an existing system.
To my understanding there are four options:
- Create a branch and integrate into RoundCube [my preference - see
below] 2. Create as a plugin or as a separate or joint project 3. Grab an existing project and modify as either plugin or direct integration 4. Forget about it and use other systems for rss
If we choose option 1, then I'd like to help manage the overall development of the rss system, as well as doing some coding. However my skills are probably not up to doing this on my own. It may be necessary to separate the development as it is a significant project, and have it's own dev list [it's just a little bigger than the address book rewrite]. I think that integration is better than a plugin though due to the size of the exercise.
If option 2, then obviously we need to get this discussion off this list and move it elsewhere. I am willing to host a development forum/wiki/test server for this, and help manage it as a separate project. An RSS Reader may be too big to be just a plugin and so development as a joint project may possibly be a good idea.
If option 3, then as for option 2, however my involvement may be limited to consultation.
If option 4, well you get the idea :(
I believe that RoundCube would be seen as a better solution [it already is ;)] with an RSS reader. It would allow you to have that remote access to your feeds along with your email (again see Thunderbird), saving time and making the whole experience a bit better.
As a webmail project, my understanding is that RoundCube does not want or need to be the all encompassing solution. However I think that an RSS reader would be a welcome addition, and should not be seen going as or pushing the project down the groupware path.
All comments or thoughts on this are welcome and encouraged. :)
I figured it would be something like this:
- Integrated into the email page [my preference]
- Feed list where the folders currently sit (i.e.
Thunderbird) + maybe as a separate pane underneath like the preview pane + ability to hide email folders and show feeds + option to have multiple feeds come into one folder + Actual feed showing in the email list section + sort by seen status + Web page displayed in preview pane or new window + able to select either: * full page * full page without images * summary * etc. + Feed list stored in database along with entries from each feed + save seen/unseen status + Folder list + "drag and drop" feed links to creatable folders for future reference etc. + Forward feed link via email + opens new email with set text & hyperlink + Digg/del.icio.us/etc. this link function + added extras services via config + Feed & folders searchable
- OR have a separate page altogether based on the email page
Thanks
Sam Bailey (cyprix)
Cyprix Enterprises www.cyprix.com.au Melbourne, Australia
Planet Cyprix Blog blog.cyprix.com.au
Matt Kaatman a écrit :
Don't most browsers already have an RSS reader?
Personally, I'm most interested in using roundcube as an email client. Maybe we need a plugin infrastructure?
A plugin architecture will be nice for mail sorting API. Cyrus use sieve for example, but other application exist. Horde use an abstraction for such rules. The ugly squirrelmail is still used for its plugin architecture.
plugins are useful.
M.
I agree - I think that a plugin architecture would be a big feature for RoundCube since it would let the community contribute their own ideas to the project without affecting the mainline. Things like this and spam filtering are two examples of really good ideas for plugins.
Adam
On 1/17/07, Mathieu Lecarme mathieu@garambrogne.net wrote:
Matt Kaatman a écrit :
Don't most browsers already have an RSS reader?
Personally, I'm most interested in using roundcube as an email client. Maybe we need a plugin infrastructure?
A plugin architecture will be nice for mail sorting API. Cyrus use sieve for example, but other application exist. Horde use an abstraction for such rules. The ugly squirrelmail is still used for its plugin architecture.
plugins are useful.
M.
Sam Bailey wrote:
- 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
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 m.bueker@berlin.de wrote:
Sam Bailey wrote:
- 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 /.
I use Magpie RSS (PHP based with caching), I can implimented RSS feeds in a matter of seconds to any webpage with the API. Its open source. However, I do feel having new flashing all over the screen is distracting. I know thunderbird had RSS feed capabilities, however, I never use it. I just go to the website, so I would consider it bloat.
On Wed, 17 Jan 2007 20:16:00 +1100, Sam Bailey cyprix@cyprix.com.au wrote:
Hey Everyone,
I was thinking that an rss reader could be integrated into RoundCube. Whether this would better be added as a plugin or integrated directly I'm not sure. And again whether to build our own or use an existing system.
To my understanding there are four options: 1. Create a branch and integrate into RoundCube [my preference - see below] 2. Create as a plugin or as a separate or joint project 3. Grab an existing project and modify as either plugin or direct integration 4. Forget about it and use other systems for rss
If we choose option 1, then I'd like to help manage the overall development of the rss system, as well as doing some coding. However my skills are probably not up to doing this on my own. It may be necessary to separate the development as it is a significant project, and have it's own dev list [it's just a little bigger than the address book rewrite]. I think that integration is better than a plugin though due to the size of the exercise.
If option 2, then obviously we need to get this discussion off this list and move it elsewhere. I am willing to host a development forum/wiki/test server for this, and help manage it as a separate project. An RSS Reader may be too big to be just a plugin and so development as a joint project may possibly be a good idea.
If option 3, then as for option 2, however my involvement may be limited to consultation.
If option 4, well you get the idea :(
I believe that RoundCube would be seen as a better solution [it already is ;)] with an RSS reader. It would allow you to have that remote access to your feeds along with your email (again see Thunderbird), saving time and making the whole experience a bit better.
As a webmail project, my understanding is that RoundCube does not want or need to be the all encompassing solution. However I think that an RSS reader would be a welcome addition, and should not be seen going as or pushing the project down the groupware path.
All comments or thoughts on this are welcome and encouraged. :)
I figured it would be something like this: - Integrated into the email page [my preference] + Feed list where the folders currently sit (i.e. Thunderbird) + maybe as a separate pane underneath like the preview pane + ability to hide email folders and show feeds + option to have multiple feeds come into one folder + Actual feed showing in the email list section + sort by seen status + Web page displayed in preview pane or new window + able to select either: * full page * full page without images * summary * etc. + Feed list stored in database along with entries from each feed + save seen/unseen status + Folder list + "drag and drop" feed links to creatable folders for future reference etc. + Forward feed link via email + opens new email with set text & hyperlink + Digg/del.icio.us/etc. this link function + added extras services via config + Feed & folders searchable - OR have a separate page altogether based on the email page
Thanks
Sam Bailey (cyprix)
Cyprix Enterprises www.cyprix.com.au Melbourne, Australia
Planet Cyprix Blog blog.cyprix.com.au
I agree with clean separation of html, php and js. I agree too with
the simplicity of json, wich is part of php 5.2 and an extension for
lesser version.
But full dynamic HTML website is very hard to build, and harder to
debug.
The first step is choosing a javascript library. I use mochikit for
my work, but other exists. Firebug is a must have for developpement,
with client side logging.
The pragmatic approch is mixing generated html, and client side
building. Generated javascript must be replaced with json, wich is an
automatic javascript serialization.
The other advantage of JSON is rpc scripting.
The example of spam moving is not well choosed, javascript is for
client side interaction, mail moving must be done when the server
code is checking imap for new mail, and moving it with imap too. But,
you can use a trash button to mark a mail as spam, and doing
something with it on client side, like bayesian training.
By the way, mail moving is better done with specific server tools
like sieve, this way, with a classical mail client, the mail is on
the right place too. Ingo do this for Horde.
http://json.org/ http://mochikit.com/ http://getfirebug.com/ http://fr3.php.net/manual/fr/ref.json.php a pure php implementation of json : http://mike.teczno.com/json.html http://www.horde.org/ingo/
M.
Le 17 janv. 07 à 19:11, Brennan Stehling a écrit :
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
m.bueker@berlin.de wrote:Sam Bailey wrote:
- 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 /.
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net
I have only review MochiKit briefly. What I have used more is Prototype with Scriptaculous which Ajax and effects support which is pretty powerful. The project is also pretty popular so development is quite active. It appears MochiKit ranks up there among the Javascript libraries.
What I like about using these libraries is the cross-browser concerns could be handled outside of the RC development which can focus on what the UI does and not bugs and inconsistencies across browsers. That should save us a lot of time and effort.
As for the folder moving example, that is just a potential use of the plugin architecture. I am sure people will implement extensions we never intended, like all of the extensions for Firefox which has made the browser so popular. One feature I may add with an the extension is to add a few buttons to the toolbar to send the currently selected message to the Junk or other folder like the delete button.
And the way I would have it carry out the move is to have the Javascript capture that event, relay a JSON message back to the server to request that PHP carry out the move. And it would be great if the server could reject the move or return an error status which would relay the message to the user.
I think with the right tools (Firefox, Firebug, Venkman, JS libraries) it would not be all that difficult to build the revised UI. I am reading the book Pro Javascript Techniques by John Resig and he covers all of the work you need to do to deal with different browsers, platforms and versions. He pulls in examples which use code snippets from people like Dean Edwards and others. I already knew Javascript pretty well but he goes into such detail that I am learning a lot.
What I like about using static HTML with Javascript to develop the UI is that we can work on the HTML templates without the Javascript being active. Then once that is tested and functional we can add the Javascript, but we can also pair the Javascript with a different HTML template which is very simplified for the purpose of just working with the Javascript and verifying that it will function by just relying on blocks marked with id and class attributes. Someone who wants to contribute and just know HTML/CSS will still be able to contribute. And the same goes for someone who knows Javascript.
Brennan
On Wed, 17 Jan 2007 20:11:16 +0100, Mathieu Lecarme mathieu@garambrogne.net wrote:
I agree with clean separation of html, php and js. I agree too with the simplicity of json, wich is part of php 5.2 and an extension for lesser version. But full dynamic HTML website is very hard to build, and harder to debug. The first step is choosing a javascript library. I use mochikit for my work, but other exists. Firebug is a must have for developpement, with client side logging. The pragmatic approch is mixing generated html, and client side building. Generated javascript must be replaced with json, wich is an automatic javascript serialization. The other advantage of JSON is rpc scripting. The example of spam moving is not well choosed, javascript is for client side interaction, mail moving must be done when the server code is checking imap for new mail, and moving it with imap too. But, you can use a trash button to mark a mail as spam, and doing something with it on client side, like bayesian training. By the way, mail moving is better done with specific server tools like sieve, this way, with a classical mail client, the mail is on the right place too. Ingo do this for Horde.
http://json.org/ http://mochikit.com/ http://getfirebug.com/ http://fr3.php.net/manual/fr/ref.json.php a pure php implementation of json : http://mike.teczno.com/json.html http://www.horde.org/ingo/
M.
Le 17 janv. 07 à 19:11, Brennan Stehling a écrit :
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 m.bueker@berlin.de wrote:
Sam Bailey wrote:
- 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 /.
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net
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.
- How are the discussions going along the speeding up the release
cycle, by focusing on the active tickets for each release?
- 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?
- Without a plugin system, how would we go about writing a plugin, such
as this RSS reader?
- 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 m.bueker@berlin.de wrote:
Sam Bailey wrote:
- 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 /.
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
On Thu, 18 Jan 2007 10:02:53 +1100, Sam Bailey cyprix@cyprix.com.au wrote:
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.
- How are the discussions going along the speeding up the release
cycle, by focusing on the active tickets for each release?
- 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?
- Without a plugin system, how would we go about writing a plugin, such
as this RSS reader?
- 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 m.bueker@berlin.de
wrote:
Sam Bailey wrote:
- 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 /.
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
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
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 brennan@offwhite.net 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 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
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 brennan@offwhite.net
Ok,
Here is a simple working example.
http://brennan.offwhite.net/rcdev/test1.html
It is using Scriptaculous and the little events library from Dean Edwards.
http://wiki.script.aculo.us/scriptaculous/ http://dean.edwards.name/weblog/2005/10/add-event2/
The custom code is inline in the page. This simulates a message tray and a folder tray. You can drag messages onto folders. The first message is not allowed and the event is canceled. The other messages are allowed and write output to the top to indicate which message was drop into which folder.
It could be extended further to loop through other folder handler methods.
What I have not done is completely model the data in Javascript. What I would do is hold the collection of message objects as a property of a RoundCubeClient object. The MessageTray would be swapped out with content when a message is being displayed and changed back to the list of messages when a folder is activated. But plugin events could also write to the MessageTray.
The next step could be to load the collection of Message objects using a JSON message pulled from the server which is rendered to the MessageTray. And then the event wrappers can be place around certain actions.
The really useful piece in the above example is the addEvent method from the Dean Edwards events library which is just 70 lines long. You can attach events to HTML elements. I used it here to attach a double-click even to the messages.
Go ahead and see what you could can do with this example. I did not do much with the stylesheet to display this in a friendly way, but it could be made to look much better.
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
Looks good so far. I've also used those libraries before, so that makes it a bit easier for me. The only worry with the libraries is that they are quite large. On the flip side though using them takes away the worries of cross-browser javascript from the RoundCube team.
Would the plugin call the OnMessageMoving & OnMessageMoved functions or does the plugin write what is in those functions? No hang on I think I've got it now. The plugin or RC core function writes the contents of the functions to do what is necessary right?
Based on that I like it - and it sets out a basic structure that the plugin or RC function needs to follow. Just like filling in the gaps.
Why would you swap out the message tray content? Maybe I'm thinking too specifically in reference the the RSS reader.
What does this mean?
What I would do is hold the collection of message objects as a property of a RoundCubeClient object.
May we should start a list of event handlers/wrappers. Obviously there will be a lot of them, but maybe try and get the basics down. Then we can try to get them interacting together safely.
I haven't used JSON before, only AJAX requests, so I'll be off to learn how it all works. Don't worry about the stylesheet, as long as it is functional that is all we need for the moment.
The above message may seem a bit jumpy in terms of content, sorry about that - I think my brain as been overheating today.
Sam
Brennan Stehling wrote:
Ok,
Here is a simple working example.
http://brennan.offwhite.net/rcdev/test1.html
It is using Scriptaculous and the little events library from Dean Edwards.
http://wiki.script.aculo.us/scriptaculous/ http://dean.edwards.name/weblog/2005/10/add-event2/
The custom code is inline in the page. This simulates a message tray and a folder tray. You can drag messages onto folders. The first message is not allowed and the event is canceled. The other messages are allowed and write output to the top to indicate which message was drop into which folder.
It could be extended further to loop through other folder handler methods.
What I have not done is completely model the data in Javascript. What I would do is hold the collection of message objects as a property of a RoundCubeClient object. The MessageTray would be swapped out with content when a message is being displayed and changed back to the list of messages when a folder is activated. But plugin events could also write to the MessageTray.
The next step could be to load the collection of Message objects using a JSON message pulled from the server which is rendered to the MessageTray. And then the event wrappers can be place around certain actions.
The really useful piece in the above example is the addEvent method from the Dean Edwards events library which is just 70 lines long. You can attach events to HTML elements. I used it here to attach a double-click even to the messages.
Go ahead and see what you could can do with this example. I did not do much with the stylesheet to display this in a friendly way, but it could be made to look much better.
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
May we should start a list of event handlers/wrappers. Obviously there will be a lot of them, but maybe try and get the basics down. Then we can try to get them interacting together safely.
Have a look of dotclear website, the plugin architecture is small and nice. You have to manage event, but also preference panel, persistance, and little thing like i18n, icon, and templating (with widgets).
I haven't used JSON before, only AJAX requests, so I'll be off to learn how it all works. Don't worry about the stylesheet, as long as it is functional that is all we need for the moment.
JSON is just a serialization, with a javascript syntax. From javascript you use it like ajax, with a callback, but without XML parsing.
M.
I agree with scriptolicious being a big library for the roundcube project. There would be so many redundant functionality in the library that we just dont need. I would suggest looking at either of
- moo.fx - http://moofx.mad4milk.net/
- jqeury - http://jquery.com/
for a small, documented and cross browser solutions to use. Both compress down to under 20k and looking at RC's javascript this is posible to get down to this size or under with the existing JS.
They both use a javascript compression http://www.phpclasses.org/browse/package/3158.html system developed by Andrea Giammarchi. Which i think sould maybe be considered as an addition to the core of Roundcube. When a plugin is newly activated in the roundcube enviroment the compressor is called to create one compress Js file.
Other advantages of useing these libraries are an already strong team of developers working toward a clean javascript library and documented functions.
Shane
On Thu, 18 Jan 2007 10:12:20 +0100, Mathieu Lecarme mathieu@garambrogne.net wrote:
May we should start a list of event handlers/wrappers. Obviously there will be a lot of them, but maybe try and get the basics down. Then we can try to get them interacting together safely.
Have a look of dotclear website, the plugin architecture is small and nice. You have to manage event, but also preference panel, persistance, and little thing like i18n, icon, and templating (with widgets).
I haven't used JSON before, only AJAX requests, so I'll be off to learn how it all works. Don't worry about the stylesheet, as long as it is functional that is all we need for the moment.
JSON is just a serialization, with a javascript syntax. From javascript you use it like ajax, with a callback, but without XML parsing.
M.
Variety is the spice of life .. except in Thailand where the spice makes your life slip out your arsehole.
The OnMessageMoving & OnMessageMoved methods would be internal to the RoundCubeClient object. Inside those methods there needs to be a way to run the configured plugins. That is the area which which will require a good deal of planning.
What does this mean?
What I would do is hold the collection of message objects as a property
of a RoundCubeClient object.
What I mean here is the following:
var rc = new RoundCubeClient(); var folders = rc.getFolders(); var messages = rc.getMessages(); rc.renderFolders(folders); rc.activateFolder(RC.INBOX); // RC.INBOX is a constant defining the Inbox
Internally I see the RoundCubeClient acting as the traffic cop for all data going to and from the server. It will hold references to all of the data. It will also render that data to the web page. But the HTML elements rendered to the MessageTray and FolderTray are only renderings of the data held in the RoundCubeClient. A plugin could completely replace the content in the MessageTray and then call rc.activateFolder(RC.INBOX) to render the MessageTray with a list of messages in the Inbox.
On the server we would have a folder called plugins. We could follow the way that WordPress plugins work. They just have you drop folders into the plugins folder and the folder name is used to define the plugin. So for an RSS reader plugin I would have the following structure.
plugins
RssReaderPlugin
RssReader.xml
RssReader.js
RssReader.php
RssReaderConfig.php
media
RssReader.css
RssReaderIcon.png
A few things here are implicit requirements. First the new plugin must be added to the plugins folder and the folder name must end in Plugin. You could deactivate a plugin by simply added _off to the folder name, which is a convenient way to preload this folder with several inactive plugins.
The remaining files like the xml, js and php files are named to match the folder name. If these files do not exist the plugin will not be activated.
As for Javascript libraries, scriptaculous.js is 2.3k and if it needs one of the other scripts it loads them as needed. Fortunately this is run as an application and these scripts will just load when the application is first started. I assume that the mail messages which I view sometimes are much bigger than a few kb, so I think it is acceptable. It is something we can keep an eye on. What I like about Scriptaculous is that we could use it as the standard JS library and all plugins will be able to assume that is there. To script against it they can use the Scriptaculous wiki for the documentation.
Here are the file sizes:
4.5K Jan 17 21:22 builder.js 28K Jan 17 21:22 controls.js 30K Jan 17 21:22 dragdrop.js 32K Jan 17 21:22 effects.js 2.2K Jul 4 2006 events.js 63K Jan 17 21:31 prototype.js 2.3K Jan 17 21:22 scriptaculous.js 10K Jan 17 21:22 slider.js 19K Jan 17 21:22 unittest.js
Brennan
On Thu, 18 Jan 2007 17:34:12 +1100, Sam Bailey cyprix@cyprix.com.au wrote:
Looks good so far. I've also used those libraries before, so that makes it a bit easier for me. The only worry with the libraries is that they are quite large. On the flip side though using them takes away the worries of cross-browser javascript from the RoundCube team.
Would the plugin call the OnMessageMoving & OnMessageMoved functions or does the plugin write what is in those functions? No hang on I think I've got it now. The plugin or RC core function writes the contents of the functions to do what is necessary right?
Based on that I like it - and it sets out a basic structure that the plugin or RC function needs to follow. Just like filling in the gaps.
Why would you swap out the message tray content? Maybe I'm thinking too specifically in reference the the RSS reader.
What does this mean?
What I would do is hold the collection of message objects as a property
of a RoundCubeClient object.
May we should start a list of event handlers/wrappers. Obviously there will be a lot of them, but maybe try and get the basics down. Then we can try to get them interacting together safely.
I haven't used JSON before, only AJAX requests, so I'll be off to learn how it all works. Don't worry about the stylesheet, as long as it is functional that is all we need for the moment.
The above message may seem a bit jumpy in terms of content, sorry about that - I think my brain as been overheating today.
Sam
Brennan Stehling wrote:
Ok,
Here is a simple working example.
http://brennan.offwhite.net/rcdev/test1.html
It is using Scriptaculous and the little events library from Dean
Edwards.
http://wiki.script.aculo.us/scriptaculous/ http://dean.edwards.name/weblog/2005/10/add-event2/
The custom code is inline in the page. This simulates a message tray
and a folder tray. You can drag messages onto folders. The first message is not allowed and the event is canceled. The other messages are allowed and write output to the top to indicate which message was drop into which folder.
It could be extended further to loop through other folder handler
methods.
What I have not done is completely model the data in Javascript. What I
would do is hold the collection of message objects as a property of a RoundCubeClient object. The MessageTray would be swapped out with content when a message is being displayed and changed back to the list of messages when a folder is activated. But plugin events could also write to the MessageTray.
The next step could be to load the collection of Message objects using a
JSON message pulled from the server which is rendered to the MessageTray. And then the event wrappers can be place around certain actions.
The really useful piece in the above example is the addEvent method from
the Dean Edwards events library which is just 70 lines long. You can attach events to HTML elements. I used it here to attach a double-click even to the messages.
Go ahead and see what you could can do with this example. I did not do
much with the stylesheet to display this in a friendly way, but it could be made to look much better.
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
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
I am OK with any Javascript library which is small but also handles all of our needs.
It needs to help manage events, handle drag/drop and also offer a few effects to produce a modern web UI.
And it definitely needs to have online documentation which we can use.
What we need to do is come up with a list of requirements for a Javascript library and then we can evaluate each available library to see which ones fill the requirements. I still like the Dean Edwards event library. It is small and just handles the cross-browser events API. It has not effects or drag/drop, but will allow us to reliably attach our custom behavior.
http://brennan.offwhite.net/rcdev/scripts/events.js
Sam,
As you work through your list of hooks for the plugin, could you maintain a list of potential requirements for the Javascript library?
Brennan
On Thu, 18 Jan 2007 4:04:48 -0600, Gnative shane@gnative.com wrote:
I agree with scriptolicious being a big library for the roundcube project. There would be so many redundant functionality in the library that we just dont need. I would suggest looking at either of
- moo.fx - http://moofx.mad4milk.net/
- jqeury - http://jquery.com/
for a small, documented and cross browser solutions to use. Both compress down to under 20k and looking at RC's javascript this is posible to get down to this size or under with the existing JS.
They both use a javascript compression http://www.phpclasses.org/browse/package/3158.html system developed by Andrea Giammarchi. Which i think sould maybe be considered as an addition to the core of Roundcube. When a plugin is newly activated in the roundcube enviroment the compressor is called to create one compress Js file.
Other advantages of useing these libraries are an already strong team of developers working toward a clean javascript library and documented functions.
Shane
On Thu, 18 Jan 2007 10:12:20 +0100, Mathieu Lecarme mathieu@garambrogne.net wrote:
May we should start a list of event handlers/wrappers. Obviously there will be a lot of them, but maybe try and get the basics down. Then we can try to get them interacting together safely.
Have a look of dotclear website, the plugin architecture is small and nice. You have to manage event, but also preference panel, persistance, and little thing like i18n, icon, and templating (with widgets).
I haven't used JSON before, only AJAX requests, so I'll be off to learn how it all works. Don't worry about the stylesheet, as long as it is functional that is all we need for the moment.
JSON is just a serialization, with a javascript syntax. From javascript you use it like ajax, with a callback, but without XML parsing.
M.
Variety is the spice of life .. except in Thailand where the spice makes your life slip out your arsehole.
Brennan,
Reading through the transcript from the meeting I see that I got a small mention.
Instead of looking specifically at hooks, what I've decided to do is build my RSS Reader based on the current mail task. From there I can then go backwards and see what I wanted to use, look at how it currently works, and work out what we need. Doing it this way also is allowing me to learn more about how the RC architecture works so that I can contribute more later on. It also lets me check out what we need in: php, js, css, localization etc.
My first screenshot is at: http://www.cyprix.com.au/devel/rss/screenshot1.png
Sam Bailey
Brennan Stehling wrote:
I am OK with any Javascript library which is small but also handles all of our needs.
It needs to help manage events, handle drag/drop and also offer a few effects to produce a modern web UI.
And it definitely needs to have online documentation which we can use.
What we need to do is come up with a list of requirements for a Javascript library and then we can evaluate each available library to see which ones fill the requirements. I still like the Dean Edwards event library. It is small and just handles the cross-browser events API. It has not effects or drag/drop, but will allow us to reliably attach our custom behavior.
http://brennan.offwhite.net/rcdev/scripts/events.js
Sam,
As you work through your list of hooks for the plugin, could you maintain a list of potential requirements for the Javascript library?
Brennan
On Thu, 18 Jan 2007 4:04:48 -0600, Gnative shane@gnative.com wrote:
I agree with scriptolicious being a big library for the roundcube project. There would be so many redundant functionality in the library that we just dont need. I would suggest looking at either of
- moo.fx - http://moofx.mad4milk.net/
- jqeury - http://jquery.com/
for a small, documented and cross browser solutions to use. Both compress down to under 20k and looking at RC's javascript this is posible to get down to this size or under with the existing JS.
They both use a javascript compression http://www.phpclasses.org/browse/package/3158.html system developed by Andrea Giammarchi. Which i think sould maybe be considered as an addition to the core of Roundcube. When a plugin is newly activated in the roundcube enviroment the compressor is called to create one compress Js file.
Other advantages of useing these libraries are an already strong team of developers working toward a clean javascript library and documented functions.
Shane
On Thu, 18 Jan 2007 10:12:20 +0100, Mathieu Lecarme mathieu@garambrogne.net wrote:
May we should start a list of event handlers/wrappers. Obviously there will be a lot of them, but maybe try and get the basics down. Then we can try to get them interacting together safely.
Have a look of dotclear website, the plugin architecture is small and nice. You have to manage event, but also preference panel, persistance, and little thing like i18n, icon, and templating (with widgets).
I haven't used JSON before, only AJAX requests, so I'll be off to learn how it all works. Don't worry about the stylesheet, as long as it is functional that is all we need for the moment.
JSON is just a serialization, with a javascript syntax. From javascript you use it like ajax, with a callback, but without XML parsing.
M.
Variety is the spice of life .. except in Thailand where the spice makes your life slip out your arsehole.
-
Adam Grelck -
Brennan Stehling -
Gnative -
Mathieu Lecarme -
Matt Kaatman -
Michael Bueker -
Michael Phillips -
Sam Bailey