1. 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.
2. 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.
3. 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.
4. 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 <[EMAIL PROTECTED]>',
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 <[EMAIL PROTECTED]>',
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.
5. 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.
--
Brennan Stehling
http://brennan.offwhite.net/blog/
http://www.smallsharptools.com/
