>> the mail interactions could be offloaded to a completely >> different project. Dovecot has announced gmail-api support, and >> has also floated the idea of supporting JMAP. If the rouncube >> client can just call a standard JSON API to get mail from the >> imap server, then roundcube doesn't need to worry about that >> portion at all (which would be a very good thing - >> indexing/caching/etc would all be handled by the imap server) > > but then you have to support different servers which means a ton > of combinations to test and debug - IMAP is a standard protocol
as it the goal for JMAP (http://jmap.io/). and the Gmail-API is a semi-standard protocol as well. dovecot supporting one or both will help them become more standardized. and despite being a standard, there is quite a bit of variability among IMAP servers. i see new IMAP servers (mostly on the windows side) that are broken in different ways every week. >> even if dovecot/courier/etc don't directly support any JSON APIs, >> a separate daemon could be produced to do the >> proxying/conversion. it need not be part of the roundcube project >> (there's already an IMAP->JMAP gateway/proxy >> https://github.com/jmapio/jmap-perl/blob/master/bin/server.pl). >> for hosting situations where only php is allowed, a >> non-daemonized version proxy layer could be written in php. > > again: you would have a dozen of different roundcubes no, you'd have one roundcube, with a dependency on a new standardized JSON mail access protocol. both JMAP and gmail-API aim to eliminate some of the pain involved in using IMAP for webmail. roundcube *could* try and create a new standard, or go with a proprietary protocol, but why reinvent the wheel? part of the idea being redoing roundcube is to take advantage of developments that have come up since the project was started - these two new access protocols are two such recent developments. >> the more the backend components are separated, the easier is it >> for everyone to find optimal ways to run it in their environment > flexible != easy what most people expect is "unpack a tarball in a > webhost, enter username and password, done" - you can say that you > don't care for that expectation and that these users are no longer > you target, that may be fine from your sie but at the sam emoment > would mean lose a large part of the userbase it's completely possible to distribute a version of roundcube that just works if you untar it, while still allowing people to choose to do more advanced things with it (by disabling/replacing/overriding stock components/config). such a thing would not be a unique concept in the software world. _______________________________________________ Roundcube Development discussion mailing list [email protected] http://lists.roundcube.net/mailman/listinfo/dev
