>> In the "Writing a director" documentation I *recommend* directors >> writers to back their director with a *VMOD object* because VMOD >> object come with a *unique* vcl_name and don't outlive the VCL's >> lifespan. It makes VMOD objects in my opinion the best facility to >> write a director. > > Certainly, that's a good solution -- as long as your use case allows > for it. You could even have an object generate multiple backends, > using the object's name for a "safe namespace", within which it > creates unique names (say by adding the ".%d" suffix). > > And you've made it clear that you're fully aware that using objects is > not the only, necessary solution -- and even then, the VMOD has to go > through the motions of using the object's vcl_name for backend names.
I apparently I haven't made it clear that I fully understand how VMOD objects and backends are totally unrelated, except for the vcl_name on which they can't collide. > However the VMOD goes about it, uniqueness of naming with all of the > consequences is something it has to take care of (or not, and take the > consequences). > > Adding something to the Varnish/VRT interface to make it work right > will go a long way to making this painless. > > D'accord? I don't think it's a good idea to leave the end-user with unnamed backends in the VSL that don't even appear in the CLI and VSM, or confusing names in the CLI/VSM because of name collisions auto-repair. I care way way more about the end-user's convenience rather than the VMOD writer's. Especially since the rules to follow to ensure uniqueness wouldn't even be hard, there isn't that much pain in my opinion. Best, Dridi _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
