4 ms·

I guess I'm a little confused here. As far as I can tell this isn't an email platform; it's a service that wraps IMAP and POP and exposes RESTful services. The

I guess I'm a little confused here. As far as I can tell this isn't an email platform; it's a service that wraps IMAP and POP and exposes RESTful services. The grand claims in the text makes me think they're going to provide something that replaces email addresses and provides a better protocol than IMAP but that's not what's going on as far as I can tell. Am I missing anything? I'm not trying to be an ass and IMAP and POP suck to deal with but there are hundreds of libraries that do it with very little work required. IMAP should certainly be replaced with something better but I don't see a proposal for such a thing.

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 ago
  Exactly.
- BinaryIdiot 12y ago
  I 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 ago
  There 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.
jmathai 12y ago
I think the best way forward is to wrap IMAP instead of trying to come up with something entirely new. The ultimate goal is a better protocol but we won't get there by simply building a better protocol.
- BinaryIdiot 12y ago
  I disagree; you take the lessons learned about the old protocol and the industry itself and you build something new. If you have to include the old you'll always be tied to supporting some of the ways it works which may prevent innovation. Naturally both of our sides are talking theoreticals so it'll be interesting to see how everything shakes out over time.
  - jmathai 12y ago
    Yes, the end goal is the same for both approaches. The reason I believe providing backwards compatability for something like email is that its probably one of the oldest and heavily used protocols people rely on today. I believe you can think of Facebook and Twitter as "new" protocols for email. It doesn't have the "open" or "distributed" nature of email but one can say that something like Diaspora did which had a terrible time gaining traction. I don't see how you can replace email without providing some level of interoperability. I'd love to be proved wrong though.
    - BinaryIdiot 12y ago
      Personally I feel like you could just offer them side-by-side until you wean off of one onto the other. But because there are no replacement protocols (at least that I know of) that have a chance to replace email who knows how feasible that is. As a developer when I approach a system that needs to be completely redone to be improved I try to look at how to best accomplish the goals, work out an implementation then figure out how to best provide backwards compatibility because I'm always worried going the other way is going to hamper the final product. It doesn't have to but that's how my mind works.
      - 12y ago
pm 12y ago
I'm quite sure that Context.IO does the same thing, as I've used it before (although they directly interfaced with IMAP).
chatmasta 12y ago
Yeah, looks like it's a platform, a.k.a. an API around your existing email. From a business and interoperability perspective, building a platform is definitely a good move. They'll be able to create an "email App Store" for developers to publish apps built on their platform, and they can take a cut of revenue. I imagine the play here is to 1) build the API, 2) build a pluggable skeleton of a frontend, 3) chase the enterprise for huge swaths of customers with unique email needs (hence the emphasis on Exchange servers), and 4) recruit developers with the value prop of making money building apps on the API and selling them to enterprise customers. I suspect the final product will look more like Google apps than it will gmail. And if the API is nice, they'll get developers, who will build unique apps, which in turn will convince enterprise customers to sign on. Acquiring customers will be especially easy if it doesn't require swapping out their email backends.

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 ago
Exactly.
BinaryIdiot 12y ago
I 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 ago
There 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.

jmathai 12y ago

I think the best way forward is to wrap IMAP instead of trying to come up with something entirely new. The ultimate goal is a better protocol but we won't get there by simply building a better protocol.

BinaryIdiot 12y ago
I disagree; you take the lessons learned about the old protocol and the industry itself and you build something new. If you have to include the old you'll always be tied to supporting some of the ways it works which may prevent innovation. Naturally both of our sides are talking theoreticals so it'll be interesting to see how everything shakes out over time.
- jmathai 12y ago
  Yes, the end goal is the same for both approaches. The reason I believe providing backwards compatability for something like email is that its probably one of the oldest and heavily used protocols people rely on today. I believe you can think of Facebook and Twitter as "new" protocols for email. It doesn't have the "open" or "distributed" nature of email but one can say that something like Diaspora did which had a terrible time gaining traction. I don't see how you can replace email without providing some level of interoperability. I'd love to be proved wrong though.
  - BinaryIdiot 12y ago
    Personally I feel like you could just offer them side-by-side until you wean off of one onto the other. But because there are no replacement protocols (at least that I know of) that have a chance to replace email who knows how feasible that is. As a developer when I approach a system that needs to be completely redone to be improved I try to look at how to best accomplish the goals, work out an implementation then figure out how to best provide backwards compatibility because I'm always worried going the other way is going to hamper the final product. It doesn't have to but that's how my mind works.
    - 12y ago

pm 12y ago

I'm quite sure that Context.IO does the same thing, as I've used it before (although they directly interfaced with IMAP).

chatmasta 12y ago

Yeah, looks like it's a platform, a.k.a. an API around your existing email. From a business and interoperability perspective, building a platform is definitely a good move. They'll be able to create an "email App Store" for developers to publish apps built on their platform, and they can take a cut of revenue. I imagine the play here is to 1) build the API, 2) build a pluggable skeleton of a frontend, 3) chase the enterprise for huge swaths of customers with unique email needs (hence the emphasis on Exchange servers), and 4) recruit developers with the value prop of making money building apps on the API and selling them to enterprise customers. I suspect the final product will look more like Google apps than it will gmail. And if the API is nice, they'll get developers, who will build unique apps, which in turn will convince enterprise customers to sign on. Acquiring customers will be especially easy if it doesn't require swapping out their email backends.