4 ms·

Protocols are not exclusively a good thing. People constantly try to reinvent email, but because any attempt to fix the problems requires modifying the SMTP an

by zanny 12y ago

Protocols are not exclusively a good thing. People constantly try to reinvent email, but because any attempt to fix the problems requires modifying the SMTP and IMAP protocols and formatting you are fucked from the get go because you break protocol compatibility. That is also why Wayland is having such a hard time. Every program and compositor is written against the X protocol and supplemental libraries, and any attempt to fix the protocol requires a backwards incompatible reimplementation. So protocols are not a catch all solution - they are better than just undocumented spaghetti, but protocols imply bureaucracy and inflexibility, whereas dbus and systemd and gstreamer can move fast and break things without being beholden to a big beefy documented protocol standard to also break and try to get people to transition on.

quotemstr 12y ago
Do you really think the world would be better place right now if email had been distributed as a library and not as a protocol anyone could implement? How could that possibly have worked? And how could it possibly have solved compatibility problems? It's not as if you can get everyone to upgrade libraries simultaneously.
- zanny 12y ago
  The library becomes the de facto protocol. The difference is that there is a mindshare that updating libraries to stay current is less intrusive than having a protocol revision change break backwards compatibility. I don't necessary think it would have been better, or even feasible, just that it is a situational quandary, not just the black and white "protocols always win". Protocols enable interoperability at the cost of rigidity and resistance to change. You should protocolize when you are are damn sure you aren't changing anything else, and there have been very few technologies where you can say the protocols conceived a decade ago are still problem free today.
jude- 12y ago
> whereas dbus and systemd and gstreamer can move fast and break things I think you will find that this attitude is exactly the opposite of what is expected at the plumbing layer. Move fast and break things is fine when no layers depend on you to remain stable (see also, the Web). Imagine how hellish life would be if Linus et al. took this attitude towards kernel development.
- zanny 12y ago
  The kernel does not have a stable ABI, and none of the developers really commit to significant backwards compatibility - they just maintain LTS kernel tree branches for those that want to stay in one spot. The same thing happened with the gstreamer 0.x and 1.x forks, except every Linux release is effectively a new GST release, albeit the APIs userspace uses against the kernel rarely break, it is a huge spread of APIs and one or another usually does change each release.
  - pdkl95 12y ago
    Can I use software written for an release (lets say 0.8.x) of gstreamer, and have it run correctly against a modern release (such as 1.2.x or 1.4.x)? Because that works with th kernel, as it most certainly does have a stable userspace ABI. Internal stability is not a big concern unless you're trying to hide the source code (proprietary driver). Linus' guarantee about not breaking userspace is very widely known, so I'm sure you know this. The GP was absolutely correct: while you have the luxury of being able to "move fast and break things" as a leaf app that nobody depends on[1], for most everything else "reliability" and "doesn't give me lots of extra work" are far more important than any other feature. This is really just an extension of why it is considered a good idea to write maintainable, modular code instead of leaving people with a mess of spaghetti to debug. [1] That changes if your userspace grows and people ARE depending on it.

by zanny 12y ago

quotemstr 12y ago

Do you really think the world would be better place right now if email had been distributed as a library and not as a protocol anyone could implement? How could that possibly have worked? And how could it possibly have solved compatibility problems? It's not as if you can get everyone to upgrade libraries simultaneously.

zanny 12y ago
The library becomes the de facto protocol. The difference is that there is a mindshare that updating libraries to stay current is less intrusive than having a protocol revision change break backwards compatibility. I don't necessary think it would have been better, or even feasible, just that it is a situational quandary, not just the black and white "protocols always win". Protocols enable interoperability at the cost of rigidity and resistance to change. You should protocolize when you are are damn sure you aren't changing anything else, and there have been very few technologies where you can say the protocols conceived a decade ago are still problem free today.

jude- 12y ago

> whereas dbus and systemd and gstreamer can move fast and break things I think you will find that this attitude is exactly the opposite of what is expected at the plumbing layer. Move fast and break things is fine when no layers depend on you to remain stable (see also, the Web). Imagine how hellish life would be if Linus et al. took this attitude towards kernel development.

zanny 12y ago
The kernel does not have a stable ABI, and none of the developers really commit to significant backwards compatibility - they just maintain LTS kernel tree branches for those that want to stay in one spot. The same thing happened with the gstreamer 0.x and 1.x forks, except every Linux release is effectively a new GST release, albeit the APIs userspace uses against the kernel rarely break, it is a huge spread of APIs and one or another usually does change each release.
- pdkl95 12y ago
  Can I use software written for an release (lets say 0.8.x) of gstreamer, and have it run correctly against a modern release (such as 1.2.x or 1.4.x)? Because that works with th kernel, as it most certainly does have a stable userspace ABI. Internal stability is not a big concern unless you're trying to hide the source code (proprietary driver). Linus' guarantee about not breaking userspace is very widely known, so I'm sure you know this. The GP was absolutely correct: while you have the luxury of being able to "move fast and break things" as a leaf app that nobody depends on[1], for most everything else "reliability" and "doesn't give me lots of extra work" are far more important than any other feature. This is really just an extension of why it is considered a good idea to write maintainable, modular code instead of leaving people with a mess of spaghetti to debug. [1] That changes if your userspace grows and people ARE depending on it.