So I have been working on a web based mail client, and I have taken the
approach of the client keeping mail in its own database, so it can do
its own indexing, organisation, and search of the email. I understand
this gets away from a purely standards based approach. Lots of webmail
clients seem to be just wrappers that pass through to IMAP, while
desktop email applications like Thunderbrid, etc, take the approach of
syncing mail to their own database. This allows for more complex
searches and greater speed than the IMAP protocol can deliver. Also a
message database does not have to limit itself to traditional email. It
could have inputs and outputs to other protocols that provide better
trust, security, etc, than SMTP and friends.
That being said, it would be nice if there was a standard http based
messaging service protocol. My code ( yrcloud.com ) is currently
written using Django and JSON-RPC, but I have been thinking a bit that
maybe a NoSQL database with a JSON-REST interface might be a more
general approach to take. I have a bit to learn before deciding if such
a switch is worth it though. Regardless, such a system would need
gateways to the traditional IMAP/POP3/SMTP protocol set, but could also
include gateways to things like Diaspora or Status.net.
I am using gmail as my inspiration here. Gmail is fast, lets you do
complex searches fast, organises messages by threads automatically and
very well, has tagging, filters, etc. I don't think anyone could
implement a Gmail equivalent as an IMAP pass through. It would have to
have a richer schema and set of search functions than that.
On 02/28/2011 12:02 AM, Thomas Lord wrote:
On Sun, 2011-02-27 at 22:17 -0500, Dave Crossland wrote:
On 27 February 2011 15:37, Thomas Lord<[email protected]> wrote:
Are there (that you know of) any Web MUAs that, by design,
more "API-centric"?
Node.JS and CoffeeScript to the rescue?
One way or another it is looking like something that
unfortunately would have to be written to be used
for Freedombox.
My goal here is to reduce the most basic communications
and social networking capabilities to a small set
of fundamental services implemented very flexibly -
and then have an ecosystem of pluggable web clients
that exist on top of that just statically served.
For example, consider a "private message" feature
in a client that provides a Facebook-style interface
and an ordinary web mail client. Ideally, the underlying
dynamic server-side app for both is nothing more than
an ordinary IMAP server with some thin-as-practical
HTTP API glue on top of it. (It can't be too thin.
Web clients need help parsing messages, handling
attachments, etc.) Ideally, the clients are
otherwise served up static and the APIs are well enough
defined that users can have a choice of clients and
client authors can compete -- all against the
same fundamental services on the back end.
More on this later but the gap in imap<->http
is the first big "missing piece" I've found. Plenty
more places to look for missing pieces, though :-)
-t
_______________________________________________
Freedombox-discuss mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
_______________________________________________
Freedombox-discuss mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
