relative imports and duplicate includes

[Poul-Henning Kamp]

--------
In message <CABaBnj6zzj6pf6KoUS=h7nBu5zF1e2pif+vg7BQmtOXLPPBwwQ at 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
phk at 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.