Thank you all for this vital discussion! We're clearly scratching some more aspects that also can have some influence on the architectural decisions. Let my try to give some answers to the recently posed questions and remarks in one go.
@Günter: maybe you're right and persistent connections are not that much of an issue as there are some tools available to work around that. And the fact that long running scripts are not allowed by some hosters is another argument. Although when using node.js, that is by its architecture a long running process and I don't think we might find this kind of limitations here. @Harald: the question about the target audience is actually very good and we haven't clearly wrapped our heads around that yet. While the initial goal of Roundcube was to be an easy untar+upload type of software I think that the focus meanwhile changed a bit and we should not make this a blocker criteria. Over the past years, Roundcube has grown into a serious option for enterprise-level installations and many ISPs offer it as part of their software collection. Furthermore, there are many package repositories offering Roundcube for installation with all the necessary configuration for database and webserver included. And we clearly see the differing requirements for enterprise installations vs. private hosting setups. For example one does not want the config files to be in the document root. @martijn: to summarize the long answer to Harald and answer your question: I think we should more focus on professional hosting solutions rather than copy & past installations for everybody who has some webspace. New deployment tools like Docker will cover a slightly more complex installation and configuration process for you. But that doesn't mean we shall not try to make it work for both scenarios. @Günter: by a client-server application I don't mean that we need persistent connections through sockets and daemon-like server processes for Roundcube. In fact, Roundcube already IS a client-server application and using single short-lived HTTP requests to exchange data between the two sides is perfectly fine. @Michael: I think we're clearly moving towards a thick client approach for Roundcube Next. Because browsers (which is our client environment) became very powerful, we want to move more application logic to the client which certainly will have a "thickening" effect. How mobile clients can scale is yet to be figured out. But with a smart module-based architecture and a strict synchronization protocol we can maybe tailor individual less-featured clients for mobile devices. @Brendan: both JMAP and the Gmail-API are valid models for what Roundcube Next might use for its client-server communication and we might save us some time and gain some more sales argument for building a client that is compatible with either one of them. Unfortunately, I found both not being complete to synchronize the data model we want for Roundcube. And yes, Roundcube 1.x will still be around for a while. The entire Roundcube Next topic is currently a solely hypothetical collection of thoughts and will take a significant amount of time to become functional and an actual replacement for the current versions. So you all have plenty of time to prepare both your systems and your users for this eventual big update. Kind regards, Thomas _______________________________________________ Roundcube Development discussion mailing list [email protected] http://lists.roundcube.net/mailman/listinfo/dev
