Client rewrite for RoundCube

Brennan Stehling brennan at offwhite.net
Tue Aug 29 01:44:52 CEST 2006


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 at 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 at offwhite.net





More information about the Dev mailing list