Hi Brennan,
I understand your concepts for enhancing the client code of RoundCube and I mostly agree with your ideas. The current code is very straight forward and grew with the application. It currently counts about 3900 lines! All actions are held in one object and are (mostly) invoked using one method: rcube.command();
I already wanted to split the code into task-specific files such as mail, address book and settings where all methods are added to the main class using rcube_webmail.prototype.nnn. Also creating some new classes for list functionality etc. was in my mind.
There also popped up some plans and suggestions to make the client even more ajaxy and eliminate full page loads when switching between list, view and compose mode. Probably that's something we could include in this concept.
Actually I agree with a rewrite as you suggested, the only disadvantage I see, is that this will take some time and it will stop the current development because merging could become very difficult. That's also the reason, why I cc-ed the mailing list because that's a task that concerns all developers. For me, it's no problem because I'll go on holiday for more than a month soon and will not work on the project then.
Best regards, Thomas
2006/8/25, Brennan Stehling offwhite@gmail.com:
My approach with the frontend would be to make it much more object oriented and event-driven. Each mail folder would be represented by a folder object which would hold a series of message objects. And when you need to add a message to the display, you simply add a message to the folder object. Adding it will trigger an event to update the display. Essentially I would create a model in Javascript to represent the system and have the screens rendered from that model.
The current frontend code is writing out HTML DOM directly when the backend requests it. And there is no good way to trigger an event based on something happening with a message or folder. Like when you move a message from the current folder to another (or folder at this point), I would simply use the following code.
inboxFolder.remove(message1); trashFolder.add(message1);
A controller object (MailAgent) may wrap this behavior.
mailAgent.moveMessage(message1, inboxFolder, trashFolder);
Internally when the folders are changed at the model level they can trigger display events which update the screen as needed, like updating the page Title for the current count, the folder tray and the message tray. The counts to show are the counts for the messages held by the folder objects. It is no longer just dictated from the server-side.
And at the UI level you would have those objects: PageTitle, MessageTray, FolderTray, etc. In the FolderTray you would simply have it bound to the Folder object which holds a collection of Message objects. And since the Message objects have date and string values it would be very easy for the MessageTray to sort them on those properties.
Notice that at this point there is no HTML DOM being managed. By separating those conceptual areas you can have project volunteers focus on what they know best. I know XHTML, CSS and Javascript well and if all I did was help out by handling the UI portion of the Javascript I would be productive at it. I would not have to concern myself with how I need to interact with the mail system. I would just work with the methods and properties available on the objects I had available to me. I would work against the API of the mail model.
The same is true for the mail model. A developer could focus on enhancing the model to do some amazing stuff. Like when the message is moved from one folder to another it would trigger the server-side interaction to make that happen. If that fails, they can have the message returned back to the folder it came from to ensure UI properly matches the server-side state. And they would do so without touching any HTML DOM.
Brennan
Thomas Bruederli wrote:
Actually I agree with a rewrite as you suggested, the only disadvantage I see, is that this will take some time and it will stop the current development because merging could become very difficult. That's also the reason, why I cc-ed the mailing list because that's a task that concerns all developers. For me, it's no problem because I'll go on holiday for more than a month soon and will not work on the project then.
I can't really judge roundcube's need for an interface rewrite, although I would have some suggestions if that were to be done.
However, it probably would really slow down development, which I think shouldn't happen before the 0.1 release. IMHO, the best thing to do would be to finish up 0.1rc, debug it for a few weeks and then release 0.1. When that's released, we can continue supporting it, but also start developing an 0.2alpha, which would feature the new client.
That way, we'd have a nice and stable 0.1 for production use and enough time to thoroughly make the new interface for 0.2.
I don't think maintaining the two branches at a time would be too difficult. Important bugfixes should still be made to the 0.1 branch, but not much more.
There's my 2 cents :)
mtu
I will do what I can to help out.
What we can do is start by knocking out the code for the data model and then define the various methods and events which will draw the web screens using that data model. I think we also want to define the server-side endpoints as well.
And with Javascript I have seen how some projects simulate namespaces, so we could create the following objects.
Controller
RoundCube::Main RoundCube::UI
Data
RoundCube::Message RoundCube::Contact RoundCube::Folder
Each of these objects can be populated with JSON, which has PHP support.
Using JSON would reduce the amount of code we would need to use to serialize the model over AJAX requests.
Brennan
On Mon, 28 Aug 2006 09:41:51 +0200, "Thomas Bruederli" roundcube@gmail.com wrote:
Hi Brennan,
I understand your concepts for enhancing the client code of RoundCube and I mostly agree with your ideas. The current code is very straight forward and grew with the application. It currently counts about 3900 lines! All actions are held in one object and are (mostly) invoked using one method: rcube.command();
I already wanted to split the code into task-specific files such as mail, address book and settings where all methods are added to the main class using rcube_webmail.prototype.nnn. Also creating some new classes for list functionality etc. was in my mind.
There also popped up some plans and suggestions to make the client even more ajaxy and eliminate full page loads when switching between list, view and compose mode. Probably that's something we could include in this concept.
Actually I agree with a rewrite as you suggested, the only disadvantage I see, is that this will take some time and it will stop the current development because merging could become very difficult. That's also the reason, why I cc-ed the mailing list because that's a task that concerns all developers. For me, it's no problem because I'll go on holiday for more than a month soon and will not work on the project then.
Best regards, Thomas
2006/8/25, Brennan Stehling offwhite@gmail.com:
My approach with the frontend would be to make it much more object
oriented
and event-driven. Each mail folder would be represented by a folder
object
which would hold a series of message objects. And when you need to add
a
message to the display, you simply add a message to the folder object. Adding it will trigger an event to update the display. Essentially I
would
create a model in Javascript to represent the system and have the
screens
rendered from that model.
The current frontend code is writing out HTML DOM directly when the
backend
requests it. And there is no good way to trigger an event based on something happening with a message or folder. Like when you move a
message
from the current folder to another (or folder at this point), I would
simply
use the following code.
inboxFolder.remove(message1); trashFolder.add(message1);
A controller object (MailAgent) may wrap this behavior.
mailAgent.moveMessage(message1, inboxFolder, trashFolder);
Internally when the folders are changed at the model level they can
trigger
display events which update the screen as needed, like updating the page Title for the current count, the folder tray and the message tray. The counts to show are the counts for the messages held by the folder
objects.
It is no longer just dictated from the server-side.
And at the UI level you would have those objects: PageTitle,
MessageTray,
FolderTray, etc. In the FolderTray you would simply have it bound to
the
Folder object which holds a collection of Message objects. And since
the
Message objects have date and string values it would be very easy for
the
MessageTray to sort them on those properties.
Notice that at this point there is no HTML DOM being managed. By
separating
those conceptual areas you can have project volunteers focus on what
they
know best. I know XHTML, CSS and Javascript well and if all I did was
help
out by handling the UI portion of the Javascript I would be productive
at
it. I would not have to concern myself with how I need to interact with
the
mail system. I would just work with the methods and properties
available on
the objects I had available to me. I would work against the API of the
model.
The same is true for the mail model. A developer could focus on
enhancing
the model to do some amazing stuff. Like when the message is moved from
one
folder to another it would trigger the server-side interaction to make
that
happen. If that fails, they can have the message returned back to the folder it came from to ensure UI properly matches the server-side state. And they would do so without touching any HTML DOM.
Brennan
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net
On Aug 28, 2006, at 4:13 AM, Michael Bueker wrote:
Thomas Bruederli wrote:
Actually I agree with a rewrite as you suggested, the only disadvantage I see, is that this will take some time and it will stop the current development because merging could become very difficult. That's also the reason, why I cc-ed the mailing list because that's a task that concerns all developers. For me, it's no problem because I'll go on holiday for more than a month soon and will not work on
the project then.I can't really judge roundcube's need for an interface rewrite,
although I would have some suggestions if that were to be done.However, it probably would really slow down development, which I
think shouldn't happen before the 0.1 release. IMHO, the best thing
to do would be to finish up 0.1rc, debug it for a few weeks and
then release 0.1. When that's released, we can continue supporting
it, but also start developing an 0.2alpha, which would feature the
new client.That way, we'd have a nice and stable 0.1 for production use and
enough time to thoroughly make the new interface for 0.2.I don't think maintaining the two branches at a time would be too
difficult. Important bugfixes should still be made to the 0.1
branch, but not much more.There's my 2 cents :)
mtu
I think Brennan's idea of a re-write is a natural reaction to the
growth RoundCube has seen. It's great to hear that someone is willing
to invest the time to improve RC's already well-structured core.
However I agree with Michael that a complete re-write seems premature
at a 0.1 release. I would vote for a stable 0.1 first, so that the
general public can benefit from the hard work so far, and tide them
over until a re-write is done. That might also generate some good
feedback.
Rich
I also agree that we should have a stable version prior to experimenting this client-side approach. But I do see it as necessary going forward. Right now the server-side code has to "know" too much about the HTML structure of the web page and by making it simply run as service endpoints pushing around structured JSON messages it will allow for RoundCube to be broken up into multiple components.
In a 0.5 release we may have code in a file called RoundCube-Config.js with this code...
# endpoints
messagesEndpoint = "/roundcoube-0.5/messagesEndpoint.php"; foldersEndpoint = "/roundcoube-0.5/foldersEndpoint.php"; contactsEndpoint = "/roundcoube-0.5/contactsEndpoint.php";
Each of those endpoints will be responsible to handling specific requests and responding with JSON structured messages. It should make it very easy for a PHP developer to generate those responses and for a Javscript developer to write the code to request and consume those responses.
Here is an example of that request...
/roundcoube-0.5/messagesEndpoint.php?authToken=abc;folder=INBOX;page=1;action=getMessages
The request handler would verify the authToken and then get the messages for the inbox, for page 1. And these mail message objects represented with JSON would likely just be the header information for the mail messages while a MessageDetail would have to be sent as requested, like...
/roundcoube-0.5/messagesEndpoint.php?authToken=abc;folder=INBOX;messageNumber=4;action=getMessageDetail
That request would return the message detail for the 4th message in the INBOX. I believe with this approach we could introduce these endpoints gradually instead of all 3 at once. And it could tie directly into the existing code.
Brennan
On Mon, 28 Aug 2006 16:05:26 -0700, richs@whidbey.net wrote:
On Aug 28, 2006, at 4:13 AM, Michael Bueker wrote:
Thomas Bruederli wrote:
Actually I agree with a rewrite as you suggested, the only disadvantage I see, is that this will take some time and it will stop the current development because merging could become very difficult. That's also the reason, why I cc-ed the mailing list because that's a task that concerns all developers. For me, it's no problem because I'll go on holiday for more than a month soon and will not work on the project then.
I can't really judge roundcube's need for an interface rewrite, although I would have some suggestions if that were to be done.
However, it probably would really slow down development, which I think shouldn't happen before the 0.1 release. IMHO, the best thing to do would be to finish up 0.1rc, debug it for a few weeks and then release 0.1. When that's released, we can continue supporting it, but also start developing an 0.2alpha, which would feature the new client.
That way, we'd have a nice and stable 0.1 for production use and enough time to thoroughly make the new interface for 0.2.
I don't think maintaining the two branches at a time would be too difficult. Important bugfixes should still be made to the 0.1 branch, but not much more.
There's my 2 cents :)
mtu
I think Brennan's idea of a re-write is a natural reaction to the growth RoundCube has seen. It's great to hear that someone is willing to invest the time to improve RC's already well-structured core.
However I agree with Michael that a complete re-write seems premature at a 0.1 release. I would vote for a stable 0.1 first, so that the general public can benefit from the hard work so far, and tide them over until a re-write is done. That might also generate some good feedback.
Rich
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net
-
Brennan Stehling -
Michael Bueker -
richs＠whidbey.net -
Thomas Bruederli