Apologies - it's late here. Just resending with the correct subject.
---------- Forwarded message ----------
Hi boys and girls,
the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft
Happy to read all your feedback!
Cheers, Brennan & Till
Looks interesting so far.
I have a few thoughts/issues about it:
- this seems like a very large rewrite of the current code base - maybe
a little bit too big a change
- 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.
- would it be easier to "hack" and cleanup the current code base too
add a plugin api? eg. use php to add new js scripts at the start of a page & include php files where needed etc.
- 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.
what do you think?
By the way, if anyone wants to participate or watch the development of the RSS Reader you can follow it at http://wiki.cyprix.com.au/wiki/RoundCube_RSS_Reader or send me a message at rssreader@cyprix.com.au mailto:rssreader@cyprix.com.au
Sam (cyprix)
till wrote:
Apologies - it's late here. Just resending with the correct subject.
---------- Forwarded message ----------
Hi boys and girls,
the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft
Happy to read all your feedback!
Cheers, Brennan & Till
And as I forgot to mention,
- 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.
Sam Bailey wrote:
Looks interesting so far.
I have a few thoughts/issues about it:
- this seems like a very large rewrite of the current code base -
maybe a little bit too big a change
- 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.
- would it be easier to "hack" and cleanup the current code base too
add a plugin api? eg. use php to add new js scripts at the start of a page & include php files where needed etc.
- 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.
what do you think?
By the way, if anyone wants to participate or watch the development of the RSS Reader you can follow it at http://wiki.cyprix.com.au/wiki/RoundCube_RSS_Reader or send me a message at rssreader@cyprix.com.au mailto:rssreader@cyprix.com.au
Sam (cyprix)
till wrote:
Apologies - it's late here. Just resending with the correct subject.
---------- Forwarded message ----------
Hi boys and girls,
the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft
Happy to read all your feedback!
Cheers, Brennan & Till
- 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.
Sounds great especially the JSON stuff.
Thanks for the explanation.
Sam
Brennan Stehling wrote:
- 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.
I had the same thought as your #1. This appears to be about a 75% re-architecture of the existing baseline (keeping only the IMAP interaction and the HTML layout). Is it worth that amount of volatility just to enable some plugins?
-Eric
Sam Bailey wrote:
Looks interesting so far.
I have a few thoughts/issues about it:
- this seems like a very large rewrite of the current code base -
maybe a little bit too big a change
- 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.
- would it be easier to "hack" and cleanup the current code base too
add a plugin api? eg. use php to add new js scripts at the start of a page & include php files where needed etc.
- 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.
what do you think?
By the way, if anyone wants to participate or watch the development of the RSS Reader you can follow it at http://wiki.cyprix.com.au/wiki/RoundCube_RSS_Reader or send me a message at rssreader@cyprix.com.au mailto:rssreader@cyprix.com.au
Sam (cyprix)
till wrote:
Apologies - it's late here. Just resending with the correct subject.
---------- Forwarded message ----------
Hi boys and girls,
the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft
Happy to read all your feedback!
Cheers, Brennan & Till
This design goes beyond just adding support for plugins. It completely decouples the HTML, Javascript and PHP which is currently built by the PHP side by piecing together bits of Javascript and HTML and sending it back to the web browser. It makes it hard to make a change or fix a bug without create an unwanted side effect, in my opinion. I am not a PHP coder, but I did hack a lot of Perl for a few years and my code looked a lot like this PHP code. Even though it worked I found that over time it became harder and harder to maintain. It got to the point that it was not worth the effort.
I know that by breaking up the application into the logical modules it will be possible to make more progress with much less effort on the new features people have been requesting. And while the PHP code may change in several places the HTML and CSS will pretty much stay the same.
Also, I do not know what everyone is using to edit the PHP code, but I only edit the code on my FreeBSD server with VI which does not offer support for debugging and other refactoring features that you can get for other languages. As I developed these examples I was able to use FireFox with the FireBug plugin to see what was happening in the HTML and debug the Javascript line by line. And as I pulled in the JSON messages I can see the messages and any of the contents of the AJAX requests. Having that support allowed me to put together those examples in less than an hour. I was pleasantly surprised how easy it was.
I would be happy to eliminate 75% of the PHP code if the Javascript and HTML can shoulder more of the load on the client-side where I have better tools to diagnose a bug and develop new features.
Where the PHP code still needs to be in place is the interaction with the IMAP server, the MySQL database and the authentication scheme. But instead of using all of the code I am seeing which encodes/decodes HTML details it can just focus on pulling the message data from the MySQL and IMAP data sources and sending them back to the client as JSON messages which has a PHP library. I estimate that a great deal of the existing PHP will not be necessary anymore.
And with less code to maintain we can spend more time on adding more features and leave some features to be implemented by others as extensions to the core functionality.
But this will not be happening on the trunk of development. This will also be built on a branch for a next major release of RoundCube, so the existing track will stay largely the same while this is new model built.
Brennan
On 2/6/07, Eric Stadtherr estadtherr@gmail.com wrote:
I had the same thought as your #1. This appears to be about a 75% re-architecture of the existing baseline (keeping only the IMAP interaction and the HTML layout). Is it worth that amount of volatility just to enable some plugins?
-Eric
Sam Bailey wrote:
Looks interesting so far.
I have a few thoughts/issues about it:
- this seems like a very large rewrite of the current code base -
maybe a little bit too big a change
- 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.
- would it be easier to "hack" and cleanup the current code base too
add a plugin api? eg. use php to add new js scripts at the start of a page & include php files where needed etc.
- 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.
what do you think?
By the way, if anyone wants to participate or watch the development of the RSS Reader you can follow it at http://wiki.cyprix.com.au/wiki/RoundCube_RSS_Reader or send me a message at rssreader@cyprix.com.au mailto:rssreader@cyprix.com.au
Sam (cyprix)
till wrote:
Apologies - it's late here. Just resending with the correct subject.
---------- Forwarded message ----------
Hi boys and girls,
the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft
Happy to read all your feedback!
Cheers, Brennan & Till
-- *Eric Stadtherr* estadtherr@gmail.com mailto:estadtherr@gmail.com
Hi
Many thanks to Till and Brennan for their effort to bring up this draft. I share the concerns that this is a huge rewrite process and you could easily create a new project for it :-)
Basically I like the proposed architecture and it will enable things like tabs to be implemented more easily. What we will loose is the possibility to provide a non-js version of RoundCube what also has been requested once or twice. With the current code base it would be possible to realize this but once all HTML code is generated client side, this option is gone.
And second, the architecture should be capable of starting at a certain state and not at the login. For example, I'd like to right-click on a folder and choose "open in new tab" and then I expect the application to show me right that folder based on the URI the browser just opened. This goes along with the yet missing history functions that let the user click back and forward in his browser toolbar. But if we use a sophisticated library those functions should be available.
I really hope that we can implement this draft in a reasonable time. Looking at the current speed of development, I dare to doubt it...
Regards, Thomas
Sam Bailey wrote:
Looks interesting so far.
I have a few thoughts/issues about it:
- this seems like a very large rewrite of the current code base - maybe
a little bit too big a change
- 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.
- would it be easier to "hack" and cleanup the current code base too
add a plugin api? eg. use php to add new js scripts at the start of a page & include php files where needed etc.
- 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.
what do you think?
By the way, if anyone wants to participate or watch the development of the RSS Reader you can follow it at http://wiki.cyprix.com.au/wiki/RoundCube_RSS_Reader or send me a message at rssreader@cyprix.com.au mailto:rssreader@cyprix.com.au
Sam (cyprix)
till wrote:
Apologies - it's late here. Just resending with the correct subject.
---------- Forwarded message ----------
Hi boys and girls,
the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft
Happy to read all your feedback!
Cheers, Brennan & Till
till a écrit :
Apologies - it's late here. Just resending with the correct subject.
---------- Forwarded message ----------
Hi boys and girls,
the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft
Happy to read all your feedback!
Cheers, Brennan & Till
JSON is a very good idea both for js interface and distant API. Full DHTML pluggable interface is a huge change in code, but JSON server side implementation will not break anything, it may be a good starting point? With a read/write contact API I can post a protoype of AdressBook.app sync, and Thunderbird 2.0 too.
M.
I agree that dividing the project up like this and separating the html from the code is great and very progressive, but that's very javascript-centric code, it would affect which types of developers you'd be getting considerably. I, for instance, am not the greatest javascript coder, though I know my PHP pretty good... I'd probably be useless...
But there are very many pluses going for the JSON model... Especially if we were to use a good javascript library at the core.
-Arnor
On 2/7/07, Mathieu Lecarme mathieu@garambrogne.net wrote:
till a écrit :
Apologies - it's late here. Just resending with the correct subject.
---------- Forwarded message ----------
Hi boys and girls,
the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft
Happy to read all your feedback!
Cheers, Brennan & Till
JSON is a very good idea both for js interface and distant API. Full DHTML pluggable interface is a huge change in code, but JSON server side implementation will not break anything, it may be a good starting point? With a read/write contact API I can post a protoype of AdressBook.app sync, and Thunderbird 2.0 too.
M.
Hola!!
So after checking out the API draft, I must say Roundcube looks even more delicious. AJAX is amazing, and even more so are you AJAX devs. DAMN!!!!!
Anyways, while my strength is pretty much limited to PHP, this is what i can say about the API, with my limited knowledge of how RC is written. Little by little, I am going over how RC is written..
All hook placements look good. I can't think of anywhere else to put them. As I learn the RC source code and I see a place where a hook could be, I'll ping the list here...
As a side note, the current language pack is not es_ES but rather a different dialect... I'm not sure, but I think it's Chilean. I am going to contribute the es_ES lang pack (either adding it to the lang list or replacing the current)...
Juan
---------- Arnór Heiðar wrote ----------
I agree that dividing the project up like this and separating the html from the code is great and very progressive, but that's very javascript-centric code, it would affect which types of developers you'd be getting considerably. I, for instance, am not the greatest javascript coder, though I know my PHP pretty good... I'd probably be useless...
But there are very many pluses going for the JSON model... Especially if we were to use a good javascript library at the core.
-Arnor
On 2/7/07, Mathieu Lecarme mathieu@garambrogne.net wrote:
till a écrit :
Apologies - it's late here. Just resending with the correct subject.
---------- Forwarded message ----------
Hi boys and girls,
the draft is here: http://trac.roundcube.net/trac.cgi/wiki/Plugin_API_Draft
Happy to read all your feedback!
Cheers, Brennan & Till
JSON is a very good idea both for js interface and distant API. Full DHTML pluggable interface is a huge change in code, but JSON server side implementation will not break anything, it may be a good starting point? With a read/write contact API I can post a protoype of AdressBook.app sync, and Thunderbird 2.0 too.
M.
!DSPAM:1,45ca264a324484341035670!
Hi Till,
sounds amazing... :-)
Does that concept consider internationalization / localization?
How does that fit into RC concept? Where should language files be located? Who takes care about them (in running mode)?
Another open question is regarding a help system. Is it planned for RC? Should there be an additional object "RCHelp" to which I can append plugin depended help messages? Is providing help for plugins mandatory...
And finally: How can I help RC team getting all that stuff up and running?
Live long and prosper Florian http://www.qv90.de
On 2/9/07, jam@qv90.de jam@qv90.de wrote:
Hi Till,
sounds amazing... :-)
Does that concept consider internationalization / localization?
How does that fit into RC concept? Where should language files be located? Who takes care about them (in running mode)?
Florian,
we're not gonna rid off of the language files. ;-)))
The objective is to reach status quo and have a Plugin API.
Another open question is regarding a help system. Is it planned for RC? Should there be an additional object "RCHelp" to which I can append plugin depended help messages? Is providing help for plugins mandatory...
I have no idea, but what exactly are you thinking about? Error messages, or do you think one needs to add pointers in the interface, like "click here to send an email" and so on?
Cheers,
Till Klampaeckel e: mailto:klimpong@gmail.com p: +491704018676 l: http://beta.plazes.com/whereis/till
Want to know what's up in Berlin?
Another open question is regarding a help system. Is it planned for RC? Should there be an additional object "RCHelp" to which I can append plugin depended help messages? Is providing help for plugins mandatory...
I have no idea, but what exactly are you thinking about? Error messages, or do you think one needs to add pointers in the interface, like "click here to send an email" and so on?
A general help contains information for end user. Basic informations about what a mail system is, how to fill out "To" field, FAQ, which options were available for what purpose and such things (and indeed on which button to click to get a mail send).
Another good idea you pointed out is help for error message. Message window is not very large. In some languages, you need more words to provide same information. So a extended error message help would also help administrator as well as users to understand what had happened (something like "IMAP does not respond" is hard to understand if you've limited knowledge about how mail systems works).
Button help can be provided as ALT-text. This should be a MUST for all plugin developer. It makes no sense to provide such a facility in core code and new buttons (provided by plugins) have no text explanation (this would also help RC to increase accessibility for people with disabilities).
Plugin help is more specific. I created a plugin for SquirrelMail which enables end-user to specify expiration days for mailboxes. I got a couple of demands to provide end user help for the plugin (e.g. What is mail expiration? Are the mails really deleted? Is recovery available?).
I know, it is sometimes boring for coder to provide sufficient help text, but I would appreciate such a function for the RC project. If this approach can eliminate a couple of end-user-questions from mailing list, it would be beneficial for all.
(One of my favorites on mailing lists were questions about "My mails disappeared, can you please recover?!" :-))
I know this is not easy to implement and maintain; I don't know how much work we need to get that up and running, but I think you should at minimum keep these things in mind, as you work on concept and code.
Live long and prosper Florian http://www.qv90.de
-
Arnór Heiðar -
Brennan Stehling -
Eric Stadtherr -
jam＠qv90.de -
Juan González -
Mathieu Lecarme -
Sam Bailey -
Thomas Bruederli -
till