>>> * If the VMOD ensures there are no duplicate vcl_names in the >>> first place, the vcl_name will not be touched. >> >>The VMOD can enforce proper uniqueness, but can't prevent against name >>collisions from other VMODs. > > ... which is why the VRT function will have to step in.
Hi guys, I just realized that a VCL_HasBackend (or VRT) function for VMODs to "ensure" uniqueness would be racy by nature. In a scenario where the backend name is "stolen" right after we check its availability. Since the intention is to have a safety net in Varnish for deduplication, the VCL_HasBackend becomes obsolete. After a quick glance at the thread again, it seems that non-VCL backends such as for instance unix-domain socket backend should eventually show up in the CLI and VSM. While I have nothing against that (quite the opposite) I don't think it can be done without breaking both ABI and API. The current statistics should be generic enough to suit any kind of backend, except maybe for the probe part. The varnish-cli on the other end is too struct backend-centric, and despite my attempt to restrict the director API to the bare minimum, cache_backend.h made it in 4.1 and cache_director.h wasn't stripped off of the VDI_ functions. I have the feeling that Geoff started a 4.1 thread and that we are also discussing things that belong post-4.1. Best, Dridi _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
