V4 VCL roadmappery...

[Poul-Henning Kamp]

"I have a plan"

(Insert obligatory Olsen Banden reply-quote here: _____)

The VCLv4 will have two distinct parts: client and backend which
will mostly run in separate threads.

After looking at various approaches, it seems to me that it will
be the easiest rebuilding, if we start from the backend side and
end up with the client side of VCLv4, so I've made the following
plan:

vcl_fetch{} becomes vcl_reponse{}
	This is a straight renaming.

	vcl_response{} is called when we have the header back from
	the backend and its main job is to validate the response,
	and pick optional procesing (gzip, gunzip, esi, non-streaming)

A new vcl_fetch{}
	This will (a little later) replace vcl_miss{} and vcl_pass{}

	Pipe (probably) doesn't go here, it's too magical.

	vcl_fetch{} is called to pick backend and polish the bereq
	for backend, including disabling conditional fetches.

	(req.backend becomes bereq.backend)

Make it possible to run vcl_fetch{} and vcl_response{} without req.*

	This is to enable them to run (to completion) in a parallel
	thread, even if the instigating client have moved on, but
	they must still be able to run on req::thread for pass.


The operation starts in a few minutes...

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