On 3/17/15 4:16 PM, Reindl Harald wrote:
Am 17.03.2015 um 22:10 schrieb Brendan:
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
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
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
if roundcube goes that way: bye
_______________________________________________
Roundcube Development discussion mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/dev
I'm not sure you understand what is being proposed. The type of
software that is being discussed would be a package that would be as
simple as you're describing to install and configure, probably easier.
The abstraction and protocol in this discussion would be between the
client and the roundcube server, not between the roundcube server and
something else. A basic "Roundcube Next" server would be a basic system
like the current roundcube with connectivity to IMAP, and SQL backend.
The newness of the system would be based around how the client and
server communicate, which would implement a client side Javascript
framework to render HTML and a server side that provides some sort of
API or protocol that the client could communicate with. The possibility
of the server component interacting with multiple types of protocols
such as JMAP and Gmail API is just like old Roundcube supporting POP3
and IMAP, which is exciting as they really are the future of messages so
I am not sure why there is so much fear over this concept. The entire
point of this project is to simplify development of this amazing
software platform, not hinder someone from easily installing the
software. As a Systems Engineer and Developer for an ISP I welcome all
the proposed ideas, and hope for a platform that can scale by separating
components, deliver performance, high availability, various data storage
backends, and a dynamic framework for simple and powerful integration of
external components.
If 'bye' is your answer to progress then good riddance.
_______________________________________________
Roundcube Development discussion mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/dev
