When SquirrelMail joined the Google SummerOfCode2007 a lot of ideas for improvement were collected. Two of those ideas were approved for the Summer of Code and the rest of them are transferred to this page to be used at a later stage. Note that these ideas are just ideas. They may need to be improved and some of them may not be implemented at all.
New HTML Filter
As a mail client, SquirrelMail needs to deal with HTML mail, inside a browser environment.
A better way is accepting things that are known to be ok and discard everything else. This is not a trivial task: in fact it resembles actually parsing the HTML specification. However, if done it would provide a lot more secure approach to displaying HTML mail.
Some base is already underway but it needs more work. Elaborate on this.
SquirrelMail has a help system for the end-users, but the current solution isn't as flexible as one could wish. This outlines some ideas that can be expanded to a full specification. The basis for this idea is that every time you click the "help" link, the current page is sent as the referrer.
- The new help system must be a class or a number of classes working together.
- It has to be written in PHP4 with as much PHP5 support as possible.
- The code must be documented using [phpDocumentor] and the plugin interface documented in the SquirrelMail developer's manual.
- All help texts will be added by SquirrelMail itself or plugins (by using hooks outside the help page classes), and will be in in the SquirrelMail gettext format. Example: _("This is a help text.")
- Plugins must be able to modify all help text sections, regardless of if the section originates from SquirrelMail itself or another plugin, and add their own pages, and add and remove sections to all help pages including help pages from other plugins. (This implies some sort of tagging.)
- Every help page must have a title. It must be possible for the plugins to modify the title in the same way as help text sections can be modified.
- There must be a default "there is no help for this page" page, with a link to the help page index.
- If already in the help text pages, the "help" link will lead to the index.
- The help page index must be constructed based on all help pages.
- If more than one plugin wants to modify the same help text section, a priority parameter determines which plugin has precedence. The plugins state their own priority on a per modification basis. SquirrelMail itself will usually play by the same rule, but will typically have lower priority for its help text sections than the plugins have.
- It must be possible for plugins to detect which other plugins are trying to modify the same help text section. This makes it possible for one of the plugins to provide a modification that suits both plugins.
- It must be possible to do all this dynamically, which will make the classes useful for other projects, but there must also be possible to pre-generate a configuration with a PHP CLI tool. (This is similar to the hook registration in SquirrelMail 1.5.2 [SVN].) The pre-generation will speed things up for programs who doesn't want to wast time on dynamic calculations, and it will be the primary way to generate help pages for SquirrelMail (typically called from config/conf.pl).
- It shall be possible to export all help texts to a [DocBook] file. (DocBook files can then be converted to other formats, such as PDF.) This will help system administrators to print paper manuals.
As part of SquirrelMail's new template system, skins that use AJAX or similar ways of making RPC calls to the core are now possible. We'd like to build a simple and highly cross-browser compatible API that knows how to parse and act upon the XML responses given by SquirrelMail's RPC interface.
A simple XML request system is already in place, but as part of this project could (should?) also be reviewed and possibly enhanced as needed.
Convert current development stream to all-UTF. There is a prototype SquirrelMail-1.4.8-UTF release, but this project would center around changing SquirrelMail 1.5.2 to UTF.