-------- In message <5636af1f.3010...@uplex.de>, Geoff Simmons writes:
>>>> But that reminds me: What was the consensus on my proposal for >>>> .%d suffix for colliding backend names ? > >The previous conversation was just you and me talking, so I don't know >if we could call anything "consensus", but one point was that with the >suffix, VBE stats would exist for every backend. Otherwise, VBE stats >are only set up for one backend with a duplicated name, and all other >backends with the same name get no stats at all. also: CLI commands to set sick/healty etc. >But you don't have to do it that way. A VMOD author can set up >everything in a struct director, implementing all of the functions in >the interface [...] Sure. And it can add it to the data structures to appear in the CLI and add VSM stats chunks. But I'd rather question the sanity of the VMOD writer, than change our architecture to accomodate such code :-) >So unless we add a requirement like "you have to call VCL_Something() >to 'register' the director/backend", so that VCL_Something() can >change the name, I don't think we can use suffixes or anything else to >enforce unique names. (And as of now, I don't see why a VMOD backend >wouldn't work even if it doesn't call VCL_Something().) I think there is merit to this, in the sense that I can see why a VMOD creating dynamic backends wouldn't want them to "pollute" the CLI and VSM. But in the case where the VMOD wants the backend to appear in the CLI/VSM, I think it is perfectly fair to disambiguate the name there, and I think it would be silly to fail the registration, because some other VMOD happened to use the same name already. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev