VCL storage discussion summary

[Poul-Henning Kamp]

--------
In message <CAJV_h0bnbgUL-P43_UyX8q_RFV06if1SjPHo21Y4g+H-ME6QcA at mail.gmail.com>
, Federico Schwindt writes:

>Regardless of the RR, any comments or guidelines to move this forward?

Having read the thread again, I suggest:

	Before vcl_backend_response{} we point beresp->storage to the next
	stevedore RR-wise. (Today we do it later, because it is a hint).

	If at the end of v_b_r{} beresp->storage is non-NULL, we use that
	stevedore and only that stevedore.

	If at the end of v_b_r{} beresp->storage is NULL, we take it to
	mean storage failure and we 50x.

	That means you can still salvage inside v_b_r{}:

		beresp->stevedore = vmod.forklift();
		if (!beresp->stevedore) {
			beresp->stevedore = Transient;
			beresp->uncacheable = True;
		}

	For compatibility, if VCL sets beresp->storage_hint, and the string
	is a stevedore name, we *also* set beresp->storage, but on failure
	we leave it alone.

I belive that gives the semantics you desire in a POLA compliant fashion ?

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