[RFC] version 2 state diagram (take 2)

[Poul-Henning Kamp]

In message <ujrodnza5z8.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=
 writes:

>I assume all the red arrows point to vcl_error()?

Yes, I didn't want to clutter the drawing with them.


>>     vcl_hash{}
>> 	Place holder for the idea that it might be desirable to
>> 	hash on more or different fields than (URL+Host:).
>>
>> 	Not fully thought through yet, may or may not happen.
>
>Strictly speaking, you need to hash on every header mentioned in
>Vary:, but you don't even have that information until you've retrieved
>at least one version of the document from the backend - and even then,
>when a new request comes in, you need to identify the requested
>document to know which headers to hash on - so it looks like we need a
>two-level hash.

You can't hash on Vary, it's a response side header.  Vary must be
handled by traversing the list of possible objects looking for matches.

>>     vcl_hit{}
>> 	Not really sure what you would do here, but you get
>> 	the chance if you dream up something.
>>
>> 	One possible thing would be to react to high hitrates
>> 	and initiate compression.
>
>...or check the time remaining before expiry and initiate a prefetch?
>You don't mention vcl_timeout, which in any case isn't called until
>after the document has expired.

My plans for vcl_timeout{} are not firm yet, but the idea is to
call vcl_timeout{} before expiry to decide on prefetching and
possibly compression.

The comment above therefore hints at the vcl_hit{} being able
to reduce the timeout for an object, so vcl_timeout{} can get
a shot at compressing it.

But lets concentrate on the "traffic" part for now, vcl_timeout{}
needs a bit more time with the thinking cap.


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