Couple notes in between the lines.
On 10/15/2013 04:06 AM, Alex Rousskov wrote:
>I have been considering way to make the "cache" directive the top level
>of a set of the caching configuration. Similar to how auth_param is the
>tope level of most auth scheme options.
>
>Would you be able to make "cache" directive accept two alternative
>parameter alongside allow/deny as the first field and then process the
>rest of the line according to that field?
>I would suggest "store-miss" and "send-hit" for those parameters.
We could do that, but I doubt that the advantages of that approach
outweigh its drawbacks:
Since each option is applied independently from others, it may only
confuse folks that are used to our usual "first matching ACL rule wins"
approach:
cache store-miss allow foo
cache send-hit allow foo
cache early deny foo
If I do not know squid it looks a bit bettr that ^^ way.
But since I know squid.. the next paragraph describe a bit what I think:
The last rule actually wins here, but the above configuration seems to
imply the opposite to folks used to looking at Squid ACLs. I know we
cannot use the "first matching rule wins" approach for some existing
directives, but are you sure this approach works better for the two new
directives we are discussing here?
Also, the "scope" keywords (store-miss and send-hit) do not blend well
with "cache" IMHO because of the overlap between "store" and "cache" as
well as between "hit" and "cache".
The advantage of your proposal is that it groups all directives under a
common "cache" prefix, but it feels like that is not enough to justify
this complexity and the "cache" prefix itself is already used in
squid.conf for other things anyway (the "cache" term is too overloaded
in Squid context).
I am happy to rename
* "reply_to_cache" to ("store_miss" or "cache_miss") or "miss_caching"
* "reply_from_cache" to ("send_hit") or "hit_sending"
A small question about the "send_hit" is it means like "send to client a
HIT" ??
if you think any of those name pairs are better.
FWIW, the primary reason I used "cache" was to show similarity or
connection with the existing "cache" option. The primary reason I used
"reply" is to stress that these new directive can work with responses,
unlike the old "cache". Reply_from_cache works pretty good IMO, but I
certainly do_not_ consider "reply_to_cache" a good name on its own!
+1 ^^
BTW, I foresee us eventually supporting a new "force" action with these
new options that will force Squid to cache something or serve a hit
despite HTTP rules saying otherwise, but that is way outside this
project scope.
+1 ^^
Eliezer
Cheers,
Alex.
