OK... I've been currently researching and prototyping an email based communication tool myself. And what you have below is nothing interesting at all. Infact it

OK... I've been currently researching and prototyping an email based communication tool myself. And what you have below is nothing interesting at all. Infact it looks like you've just noted down features from current hype and gmail and attached your name to it. Its just using web tech push crap around. You don't offer an improvement of the problem, just a way to implement the standard process using familiar technologies. The problem you are solving is "I don't like IMAP" not actal problems with IMAP. Anyway the proposed stack for those interested: ------------------------------- - RESTful API over HTTPS. (HTTPS should not be required but recommended.) - Not sure how to go about HTTP Status codes. I'm using them below, but this might be considered misuse. Must consult for verification. - Labels (instead of folders, however, tags can be hierarchal - like how Outlook renders Gmail tags with a / in them) - JSON (Maybe allow JSON & XML, but require JSON) - UTF-8 (Only encoding type allowed - used for EVERYTHING, including API endpoints and API variables USE UTF-8. Will create larger messages byte-wise for european and asian languages, but definitely worth it) "Stateless" (Whatever IMAP states are, we don't do this). We use Session Cookies, and more precisely OAuth as the de-facto standard. - Conversations as Priority - Servers should attempt to indicate conversations, and keep messages grouped together like a forum topic. This MUST be done server-side. - NO MIME ENCODING. Mime-Types as headers are very important, but NO MIME ENCODING under ANY CIRCUMSTANCES. Built-in Push - @gabor talks about clients calling an HTTP endpoint that returns as soon as a new message/s arrive. - Full Text Search - SERVER SIDE Addresses use [user]@[domain] syntax. MSAP servers are looked up via an SRV DNS request for _msap._tcp.[domain] Return is in format TTL [class] SRV [priority] [weight] [port] [target] example: SRV 0 0 443 msap.koneko-chan.net SRV 1 0 80 msap.koneko-chan.net The first is the HTTPS (SSL) endpoint, and the second is the HTTP endpoint. Lower priority is prefered, with a fallback to higher priority available. We should also recommend having an SMTP endpoint for the sake of graceful degredation. Example of "working" endpoint: http://msap-serv.koneko-chan.net/source-code http://msap-serv.koneko-chan.net/source-code