3 ms·

The problem is, if you want to replace email it needs to play nice with email. You're not going to prise that from businesses unless it's out of their cold, dea

The problem is, if you want to replace email it needs to play nice with email. You're not going to prise that from businesses unless it's out of their cold, dead hands. A distributed client/server system would probably work, and you could go via REST, but if you're wrangling data along those forms as well as trying to fluidly integrate email into the experience (as it's not going anywhere), it might be easier to spec out a data format/protocol from scratch, you could even base it off REST if that floats your boat.

deleted 14y ago
[deleted]
anujkk 14y ago
I don't think any such system can work in isolation. We would need to integrate it with existing email system and SMS and may be also HN/Twitter/G+/etc if we consider reading all these as a to-do item. One solution that comes to mind is to let users integrate their existing email accounts by allowing them to periodically fetch email through POP and converting it into to-do items. We can also add "Reply as email" and "Forward as email" actions to implement outgoing email functionality.
- nicholassmith 14y ago
  But at that stage what you want is effectively a messaging client with heavy to-do functionality, rather than some transformative. Bolting the to-do functionality on is probably a lower-hanging fruit than a new protocol. Ideally you'd need a protocol system that allows for multiple data formats to be specified through a plugin mechanism to cope with things like social networks and SMS on top of email, but then you're squarely in the territory of being at the whims and mercy of constantly ensuring the plugin works with the backend data APIs for the services (for social networks), and sticking to the letter of the RFC law for email. It's a great idea, but as they say, going to need a bigger boat.

3 ms·

The problem is, if you want to replace email it needs to play nice with email. You're not going to prise that from businesses unless it's out of their cold, dea

by nicholassmith 14y ago

deleted 14y ago
[deleted]
anujkk 14y ago
I don't think any such system can work in isolation. We would need to integrate it with existing email system and SMS and may be also HN/Twitter/G+/etc if we consider reading all these as a to-do item. One solution that comes to mind is to let users integrate their existing email accounts by allowing them to periodically fetch email through POP and converting it into to-do items. We can also add "Reply as email" and "Forward as email" actions to implement outgoing email functionality.
- nicholassmith 14y ago
  But at that stage what you want is effectively a messaging client with heavy to-do functionality, rather than some transformative. Bolting the to-do functionality on is probably a lower-hanging fruit than a new protocol. Ideally you'd need a protocol system that allows for multiple data formats to be specified through a plugin mechanism to cope with things like social networks and SMS on top of email, but then you're squarely in the territory of being at the whims and mercy of constantly ensuring the plugin works with the backend data APIs for the services (for social networks), and sticking to the letter of the RFC law for email. It's a great idea, but as they say, going to need a bigger boat.