Hacker News Reader

Comment by somat | Hacker News Reader

it was always a protocol, however it is never good when the protocol is defined by it's only implementation

My understanding is that this is the whole reason for the existence of openrsync. The people doing work on the rpki standards wanted to use rsync for one type of transfer, the standards body (IETF?) balked with a concern that the rsync protocol had only one implementation, so the openbsd folk, specifically Kristaps Dzonson stepped up and wrote a second implementation. It does not do everything rsync does but it interoperates enough for the rpki project.

https://man.openbsd.org/rpki-client

View on HN

>however it is never good when the protocol is defined by it's only implementation

One counter-example to this is in desktop GUI environments. You want one single strong reference implementation there for stability/consistent expectations of what will run. Pretty much everything that will run on the eleventh X protocol will work X.orgs X11 everywhere. Whereas the core wayland protocol is not feature complete and the reference implementation weston is weak. So every wayland compositor implements what should be core wayland protocol features in their own choice of third party lib or custom code. Like libei vs libinput vs no support at all (weston) for normal keyboard/mouse features. Software that works on one wayland won't work on others.

My point here is that strong single reference implementations prevent fragmentation. And sometimes that's important. This is not one of those cases and I'm glad to see more rsync protocol implementations.

> 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.

e.g. Wireguard

> 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.

Sure; 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.

Reply on news.ycombinator.com