3 ms·

How does this mean rsync is a protocol?

bombela 2y ago
Think ssh, http etc
somat 2y ago
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 https://man.openbsd.org/rpki-client
- 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 ago
    e.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 ago
      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.
- superkuh 2y ago
  >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.
deleted 2y ago
[deleted]

Think ssh, http etc

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 https://man.openbsd.org/rpki-client

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 ago
  e.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 ago
    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.
superkuh 2y ago
>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.

deleted 2y ago

[deleted]