IMHO the decision narrows down to deside whether to have a thick or thin client.
You would probably also take into account from which devices RC will be accessed. A thick-client approach might be too thick for smartphones, tablets and televisions.
The question here might be: Who are the intended end-users and what will they use most? The problem with that is that we can't take a look at the usage of the current RC version, because most installations work poorly with mobile devices.
Martijn Thie
-----Original Message----- From: dev-bounces@lists.roundcube.net [mailto:dev-bounces@lists.roundcube.net] On Behalf Of Michael Rasmussen Sent: dinsdag 17 maart 2015 22:41 To: dev@lists.roundcube.net Subject: Re: [RCD] Roundcube Next - a survey
On Tue, 17 Mar 2015 14:10:10 -0700 Brendan brendan@tucows.com wrote:
i'm pretty sure thomas didn't mean that and instead meant a stateless JSON protocol with most of the logic in the client application and the server doing less work overall.
IMHO the decision narrows down to deside whether to have a thick or thin client.
If a thick client architecture is chosen you could stay with PHP. On the other hand if a thin client architecture is chosen then PHP is ruled out as PHP is not geared towards an 'always on' architecture. A thin client implies a think backend which requires an independently runtime environment better suited for a stand-alone runtime. By stand-alone runtime I mean a runtime which is capable of being self sufficient.
-- Hilsen/Regards Michael Rasmussen
Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
/usr/games/fortune -es says: <Knghtbrd> xtifr - beware of james when he's off his medication =>