--------
In message <CABaBnj6zzj6pf6KoUS=h7nbu5zf1e2pif+vg7bqmtoxlppb...@mail.gmail.com>
, Kacper Wysocki writes:
>> Maybe what we really need is VCL libraries:
>>
>> library geoip geoip.vcl [from "path"];
>> ...
>> sub vcl_recv {
>> geoip.recv_stuff();
>> }
>
>Maybe? From a programmer perspective this is certainly cleaner.
>However, the people who run Varnish out there are primarily concerned
>with ops problems. Will the library/namespaces approach resonate with
>the ops folks?
My experience is that the simpler cleaner solution is always preferable,
in particular for the ops people.
The above mockup gave me a number of interesting ideas in the
subsequent shower.
DISCLAIMER: ** I'm not promising ANYTHING **
...but here are some random notes:
I don't think the mechanisms we use to implement typed arguments
to VMOD entry points would very hard to adapt also to VCL functions:
def STRING
foobar(INTEGER a1, BACKEND a2, STRING_LIST a3) {
...
}
...
sub vcl_recv {
set req.http.magic =
foobar(remote.ip.port, default_backend, req.http.cookie);
}
If that is true, it *also* means, that you can do the "reverse":
Take a bunch of VCL code, and compile it into a VMOD.
That automatically gives us different namespaces for the VCL
inside the VMOD and the main VCL.
I need to look at how it works if the VMOD compiled from VCL
imports a VMOD, but as I remember it, I think it would just Do
The Right Thing.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[email protected] | 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
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
