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 <[EMAIL PROTECTED]> 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: > > 1. this seems like a very large rewrite of the current code base - > maybe a little bit too big a change > > 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. > > 3. 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. > > 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. > > 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 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > 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* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-- Brennan Stehling http://brennan.offwhite.net/blog/ http://www.smallsharptools.com/
