4 ms·

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 t

by 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.
    - jmathai 12y ago
      I think we could have faster progress if we could implement new protocols without the legacy baggage of providing backwards compatibility. Just don't think that works for email. Offering a side-by-side option is interesting. I think that might achieve the best of both worlds. I wonder how much extra engineering work and complexity that adds, if any. It might actually be lower in the long run.
xorcist 12y ago
True. To start: IMAP is an asynchronous protocol. The impedance mismatch should be obvious. The roundtrips will kill any performance you could hope for. The right way to do this would be to do what was done for most other successful protocols and put together a new RFC with best practices, and expire the old mess ASAP. Then make room for whatever calendar extensions or send-later flags you might wish for.

by jmathai 12y ago

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.
  - jmathai 12y ago
    I think we could have faster progress if we could implement new protocols without the legacy baggage of providing backwards compatibility. Just don't think that works for email. Offering a side-by-side option is interesting. I think that might achieve the best of both worlds. I wonder how much extra engineering work and complexity that adds, if any. It might actually be lower in the long run.

xorcist 12y ago

True. To start: IMAP is an asynchronous protocol. The impedance mismatch should be obvious. The roundtrips will kill any performance you could hope for. The right way to do this would be to do what was done for most other successful protocols and put together a new RFC with best practices, and expire the old mess ASAP. Then make room for whatever calendar extensions or send-later flags you might wish for.