- this seems like a very large rewrite of the current code base - maybe a
little bit too big a change
By using FireFox with FireBug I am finding I can get a good deal done in a very short time. We will be able to leverage the existing generated HTML and static CSS for this new concept. The existing code to talk to the IMAP server will not change. And instead of emitting Javascript and HTML snippets the PHP code will just emit simple JSON messages.
- the use of a js library has it's advantages, however since I've been
developing the RSS Reader I've found that the current js base is good, and as in 1, this may be too big a change.
We will try to make use of the current Javascript code base, but to make this a maintainable system I am looking at jQuery and Prototype which are well supported by a larger community so they can adapt to new browser features and correct bugs for RC.
- would it be easier to "hack" and cleanup the current code base too add a
plugin api?
I would prefer not to hack the current system too much. It mixes the Javascript, HTML and CSS with the PHP by emitting it in snippets which are hard to update all together to make an update. This modular architecture created static HTML files which make up the structure of the UI. But beyond the HTML files, there will be certain rules which are followed so that you can completely change the HTML, CSS and graphics as long as you keep the same semantic structure. A good example of what you can do here is at CssZenGarden.com.
- on JSON however, I think it is a great idea to make the change to this,
but my knowledge is lacking in this area so I wouldn't know how to do it.
JSON is surprisingly simple and that is why it has become popular. It is just Javascript object syntax. Here is how I would add messages to the UI using a JSON message.
[ { instruction: 'addMessageToFolder', folder : 'Inbox', headers : { subject: 'Hello from Syney', time: '18:30 02.07.2007', sender : 'Sam sam@rssreader.au', bodySummary: 'I just got back from visiting...' }, { instruction: 'addMessageToFolder', folder : 'Inbox', headers : { subject: 'When do you have time?', time: '18:31 02.07.2007', sender : 'Carl carl@dnn.com', bodySummary: 'I would like meet to...' } ]
This includes 2 messages and the processInstructions method would key on the instruction value which tells it to interpret the message as a message and to add it to the Inbox. The collection of values for the headers could be passed into the Message object as the constructor. Pulling it into Javascript is just a matter of running the eval statement on it and assigning the result to a variable as is done in the example. Having PHP send a message like this instead of the full page of HTML should be much easier.
As the page first loads it will initialize the Application object which will load the control buttons, load the folders and then set the focus on the Inbox folder and pull all messages related to that active folder. That would pull in a limited set of the visible messages for the current display. It is a simple sequence of events given the example code that is already in place. Rendering the HTML to match what is already done will be trivial.
- Is setting the layout to the trays too limiting? i.e. how about adding extra pages(tasks) > of different layouts?
The template system of rc is very robust and as such I think we should look outside of just the set template.
The 3 trays is a good starting point. Pretty much every mail application I have used has these 3 groupings from Outlook, Eudora, Gmail to RC. These will provide the object oriented facilities for the normal activities that they will carry out. But this is also a web page and you can still do anything Javascript, HTML and CSS will allow you to do. There is nothing stopping a plugin from introducing a completely new set of objects which create their own HTML elements which work with a custom set of CSS and images. But the existing trays will offer places to dock relevant objects. For an RSS implementation of RC, the folder tray would hold groups of RSS feeds and the message tray can still list blog entries with the ability to preview and show a full blog entry within that construct. A blog entry could inherit the Message object and change the behavior for displaying the message, such as overriding the previewMessage and showMessage methods which the email messages may implement differently from a blog entry.
My idea is to have a very generic message object as well as a very generic folder object. Initially there will be folders in the IMAP classification which hold messages in the IMAP classification. These could be shown with a different color and implement IMAP specific behavior. But a message could also extend from a BaseMessage object and to a BlogEntry object and implement the previewMessage and showMessage methods as appropriate with the IMAP version as a working example. Certain facilities will across both of them, such as display HTML content and attachments for links.
It looks like Till and I will be doing a large part of the for the core features and then you and other third-party plugin developers can take the work as a starting point and contact me and Till with any questions.
And naturally Till and I will be updating the wiki with documentation as we go.