4 ms·
The semantics are completely different which has to be reflected in the VCL. I think keeping compatibility at the cost of sanity is pretty dangerous and disrega
by perbu 13y ago
The semantics are completely different which has to be reflected in the VCL.
I think keeping compatibility at the cost of sanity is pretty dangerous and disregarding compatibility has been one of the success factors for the Linux kernel.
- stefantalpalaru 13y ago> disregarding compatibility has been one of the success factors for the Linux kernel It's actually the other way around. Linus Torvalds dixit[1]: "One of the core kernel rules has always been that we never ever break any external interfaces. That rule has been there since day one, although it's gotten much more explicit only in the last few years. The fact that we break internal interfaces that are not visible to userland is totally irrelevant, and a total red herring." [1]. https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk https://plus.google.com/115250422803614415116/posts/hMT5kW8L... - second comment
- perbu 13y agoValid point and I clearly was under the misconception that Linux didn't care that much about the external interfaces. However, VCL is more akin the the kernel modules, relying on the internal APIs which are much less stable. When the semantics on how Varnish operates (with 4.0, the backend threads are completely new) and so the VCL language _needs_ to change in order to reflect this. The external API, made available through HTTP hasn't changed much.