3 ms·

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 alway

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.

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.