On Thu, Mar 12, 2015 at 11:48 AM, Scott Kidder <[email protected]> wrote: > I know I'm a bit late to the conversation but I still wanted to add my two > cents. While I think a fresh start for Roundcube is a good idea I think its > still a bit premature to be talking about what should be used to develop the > new system when there isn't a clear set of goals for what Roundcube Next > should include. So far the only goals I've seen laid out are: > 1. Move to a flexible framework to reduce Roundcube specific framework code > 2. Move more code like templates to the client side > 3. Move to a persistent based data connection > > Those are all good development goals but in my mind that isn't necessarily > enough to validate re-coding the whole system. While its been touched on we > don't have any written goals like adding multi-account support, GPG/PGP > encryption support, or any of the other long outstanding feature requests[1] > that aren't possible with the current system. Now seems like the perfect time > to define what functionality we want out of a new system so we can make > better decisions about what frameworks and languages to use.
Hello Scott Thanks for pointing this out. I admit that the "requirements" part of the story has been neglected a bit so let's try to look at this a little bit closer. The primary goals are still to improve the user experience and to facilitate the development environment. Looking at the list of feature requests, there are a few that are frequently requested but are difficult to be implemented with the current architecture: * Conversation view * Encryption support * Multi-account * Browser history / stateful urls * Tags for messages * Tabbed Interface * Chat/XMPP integration * Offline support Most of them (conversation view, tabbed interface, browser history, chat integration) require fundamental change in how the client is built and interacts with the server. Current Roundcube renders most screens on the server and loads the individual parts into iframes. Same for submitting data to the client (e.g. when composing messages). This mostly goes through regular form submissions to (hidden) iframes. You can imagine all sorts of problems that come with this. For example it makes it hard (or at least very inefficient) to add another message to a conversation view or properly handle browser history when iframes are involved. With complete page reloads as we have them in current Roundcube, the maintenance of application state, like for a chat widget, becomes very challenging and again inefficient. This is where the suggestion for widget-based and client-side rendering of the UI mostly comes from. Further features like multi-account support or tags call for a proper application-wide data model that can be used for widget-based rendering and synchronization between client and server. Moving the application logic to the client and reducing the client-server interaction to a synchronization-based approach also helps to make the application more reactive. Our current application logic is spread over both parts often requiring the client to "lock" the UI and wait for the server to process a request and return with new commands the client shall execute after. That's not how web applications are supposed to work in 2015. And finally there's the increasing demand for encryption support. As a matter of the fact that servers and connections cannot be trusted, the common agreement is that encryption should be done on the client. Yet another example how our current server-side rendering jeopardizes a proper and efficient implementation of encryption features and one more argument for letting the client convert a given data model (coming either from the server or from an encryption component) into a view. While this still isn't a complete list of goals, I hope it illustrates the challenges we're facing with the current architectural constraints and perfectly justifies the call for a major refactoring of the application design. Almost every consideration how to approach the most frequent feature requests comes down to the requirement of changing the client-server interaction in a fundamental way. And this IMO comes very close to a complete restart which gives us maximum freedom to make the right decisions. We'll try to collect a more concrete list of features we want to build into a possible Roundcube Next product. This can then be divided into a more tangible roadmap and eventually find its way into a crowd-funding campaign. But let's take one step at a time. Kind regards, Thomas _______________________________________________ Roundcube Development discussion mailing list [email protected] http://lists.roundcube.net/mailman/listinfo/dev
