RFC: new vcl_lookup{} proposal

[Poul-Henning Kamp]

--------
In message <CANTn4coXHExVc2k8Wj8F7256rCemj056G+wMeyGt-ckMH8X4iQ at mail.gmail.com>
, Martin Blix Grydeland writes:

A couple of months ago (!) we talked about a vcl_lookup{} function to
always follow vcl_hash{}

Vcl_lookup{} in it self is not a big problem, but it amplifies a
problem we have had since day one:

How do we merge VCL-code snippets from the user with the default
VCL in a sane and intuitive way ?

The current "default.vcl is always appended" method increasingly
breaks down, faced with more and more complicated VCLs, and it
certainly has been one of the most FAQs.

Martin proposed a modularization of the default.vcl, so that one
could do stuff like:

	sub default_vcl_recv {
	    call default_vcl_recv_xff;
	    call default_vcl_recv_check_method;
	    call default_vcl_recv_check_pass;
	    call default_vcl_recv_check_auth;
	    return (lookup);
	}

I can see this helping the high-skill users, who for all practical
purposes have written their own VCL, in particular it would help them
upgrading to a newer Varnish, since they could rely on the default
VCL where they don't have private magic.

But for the novice users, this will just make VCL even harder to
understand.

So maybe what we really need is a VCL-writer script for the beginners,
which will spit out a VCL based on a high-level description of features ?

Something along the lines of:

	Support PURGE command ?				[yes|no]
	Serve stale objects while fetching		[yes|no]
		How stale can they be ?			[2 m]
	Serve stale objects when backend is down 	[yes|no]
		How stale can they be ?			[1 h]
	Images can always be cached			[yes|no]
	Gzip compress URLs matching			[<regexp>]
	Enable ESI for URLS matching			[<regexp>]

There's probably a few more we should have on there, but you
get the idea...

Obviously, as they get more sofisticated, the users can "go native"
by modifying the generated VCL and run "raw".

Would this work ?

-- 
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.