3 ms·
It's the platform upon which a better email can be built. The IMAP/POP wrappers provide backwards compatibility, so that you don't have to stop using the old em
by cookiecaper 12y ago
It's the platform upon which a better email can be built. The IMAP/POP wrappers provide backwards compatibility, so that you don't have to stop using the old email system while the new email is built around it. At some point, theoretically, IMAP/POP can be transparently replaced with better delivery protocols.
- spang 12y agoExactly.
- BinaryIdiot 12y agoI disagree and agree. You're right in that better protocols can be swapped out in this design pattern and that's fine; most decent external service consuming code does this so it makes sense in that regard. But where I'm not convinced is in the API itself along with the location in which we are abstracting IMAP and POP at. The abstraction you could recreate most of what this service does with a language library so I don't really get why making it a service is even needed in the first place especially with so many worried about storing their data elsewhere. The API has limited ability to do push (webhooks are only good for web applications not thick or mobile applications) and I didn't really see how they're handling the dual authentication required. But as I said I didn't want to just poopoo the idea; I'm curious as to where it goes but with version 1 I don't see what usefulness it gives me as a developer.
- thibauts 12y agoThere is no new protocol or protocol features, so no "new mail system" around. Only a REST wrapper around the same old thing. You'll still have to support old clients on the other end. As far as I can see, it's only an enabler for email app builders. Not that's a bad thing at all. Still I would love to see people plug other protocols in. I guess that was your point. Making everything fit in the REST paradigm is anything but progress in my humble opinion.