3 ms·
> it is never good when the protocol is defined by it's only implementation I don't know that I'd go that far. The benefit of having only one implementation of
by josephg 2y ago
> it is never good when the protocol is defined by it's only implementation
I don't know that I'd go that far. The benefit of having only one implementation of a protocol is that the protocol can evolve much faster. You don't have to have committee meetings to tweak how it works. And as a first pass, the more iterations you make of something, the better the result.
Rsync is mature enough to benefit from multiple implementations. But I'm glad it had some time to iterate on the protocol first.
- ycombinatrix 2y agoe.g. Wireguard
- throw0101d 2y ago> The benefit of having only one implementation of a protocol is that the protocol can evolve much faster. Or you design the protocol to allow non-standard extensions, like with SSH, so you can have foo@example.com implemented by one product (and others can look for it if useful), and bar@example.org by another product. And if enough folks file the feature(s) useful they can be standardize with tweaks that fixed issues that were found though operational experience. Lots of IETF standards have a "x-" prefix mentioned for private / proprietary extensions.
- josephg 2y agoSure; but there's a limit of how much you can sensibly do with an extension mechanism. You can't - for example - change a text based protocol into a binary protocol using an extension mechanism. If you're in control of both client and server, you can change everything.