On one hand, it's a little annoying that openrsync doesn't support some features that rsync does.
On the other hand, it's great that there are multiple independent implementations of rsync now. It means that it's actually being treated as a protocol, not just a piece of software.
I'm exciting about this too. It becoming more like a protocol makes me optimistic we'll see binary diff API points based on the rsync algorithm.
fun fact: Dropbox internally used rsync binary diff to quickly upload small changes to large file. I assume they still do. But their public API endpoints don't offer this and a small change to a large file means the whole file must be updated.
It's a decent protocol, but it has shortcomings. I'd expect most future use cases for that kind of thing to reach for a content-defined chunking algorithm tuned towards their common file formats and sizes.
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.
>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.
> 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 [email protected] implemented by one product (and others can look for it if useful), and [email protected] 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.
On the other hand, it's great that there are multiple independent implementations of rsync now. It means that it's actually being treated as a protocol, not just a piece of software.