Re: Refresh patterns and ACLs
On 29/08/2008, at 11:20 PM, Henrik Nordstrom wrote: On fre, 2008-08-29 at 10:44 +1000, Mark Nottingham wrote: I'm not convinced it's a great solution, but something like URISpace may be appropriate; http://www.w3.org/TR/urispace.html Not very different in function, besides being XML.. However, the URISpace xml tag space is a bit too limited, so it needs to be extended a lot. And it's focus is a little different from what we need in a general sense (but may fit reasonably well for a reverse proxy or web server). The whole point is that it's extensible. Being XML makes it portable, encourages tool development, etc. (which is what we were looking for at Akamai). Again, I'm not saying that this is the answer -- IMO URISpace is too compex (although so is the problem space); I just despair of having yet another solution in this space; see http://www.w3.org/2007/powder/ http://xrds-simple.net/ http://www.sitemaps.org/ ad nauseum... What's nice about this is that you buy some efficiency by walking down the tree, rather than evaluating a linear set of rules... Same. Regards Henrik -- Mark Nottingham [EMAIL PROTECTED]
Re: Refresh patterns and ACLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Mark Nottingham wrote: I'm not convinced it's a great solution, but something like URISpace may be appropriate; http://www.w3.org/TR/urispace.html What's nice about this is that you buy some efficiency by walking down the tree, rather than evaluating a linear set of rules... Interesting spec: I can see uses for it elsewhere. A quick question, (since grubbing around shows you to be the author;): in section 3.3, Path Segments, the semantics of path match=foo are to match the next element in the current path, right? Rather than matching any random element (CSS style), or (for instance) the last element (which would be useful in particular for the empty pattern and filename globs). Is the spec frozen / dead, or could we suggest additions? E.g.: path any=archives and: path last= I can certainly put such extensions into another namespace, but they seem reasonably tightly connected to the existing first match semantics. BTW, I have banged out a Python implementation of a good bit of the spec, including extensions for last element and any element path selectors. I plan to use the library in conjunction with various WSGI middleware to allow for URI-based selection of things like theme, role grants, and caching headers: http://pypi.python.org/pypi/repoze.urispace (I'll work on getting the ReStructuredText on that page to render later). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIuZh2+gerLs4ltQ4RAgzmAJ40134AsAKppeA2sI1V9Ms4r67rMACgiGG+ yBJxxO12RBUI5YXmdCORo4E= =hTI9 -END PGP SIGNATURE-
Re: Refresh patterns and ACLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Tres Seaver wrote: Mark Nottingham wrote: I'm not convinced it's a great solution, but something like URISpace may be appropriate; http://www.w3.org/TR/urispace.html What's nice about this is that you buy some efficiency by walking down the tree, rather than evaluating a linear set of rules... Interesting spec: I can see uses for it elsewhere. A quick question, (since grubbing around shows you to be the author;): in section 3.3, Path Segments, the semantics of path match=foo are to match the next element in the current path, right? Rather than matching any random element (CSS style), or (for instance) the last element (which would be useful in particular for the empty pattern and filename globs). Is the spec frozen / dead, or could we suggest additions? E.g.: path any=archives and: path last= I can certainly put such extensions into another namespace, but they seem reasonably tightly connected to the existing first match semantics. BTW, I have banged out a Python implementation of a good bit of the spec, including extensions for last element and any element path selectors. I plan to use the library in conjunction with various WSGI middleware to allow for URI-based selection of things like theme, role grants, and caching headers: http://pypi.python.org/pypi/repoze.urispace (I'll work on getting the ReStructuredText on that page to render later). The PyPI page is still unrendered, but cooked versions of the docs are online here: http://static.repoze.org/urispacedocs/ Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIuZ0O+gerLs4ltQ4RAhZPAJ9q/PKve7pgOkMNkeojd9RRhLJ+zwCgvL1F iowu4qiHOq8fhgsuomi+fiQ= =eSDv -END PGP SIGNATURE-
Re: Refresh patterns and ACLs
On fre, 2008-08-29 at 10:44 +1000, Mark Nottingham wrote: I'm not convinced it's a great solution, but something like URISpace may be appropriate; http://www.w3.org/TR/urispace.html Not very different in function, besides being XML.. However, the URISpace xml tag space is a bit too limited, so it needs to be extended a lot. And it's focus is a little different from what we need in a general sense (but may fit reasonably well for a reverse proxy or web server). What's nice about this is that you buy some efficiency by walking down the tree, rather than evaluating a linear set of rules... Same. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: Refresh patterns and ACLs
On fre, 2008-08-29 at 08:38 +0800, Adrian Chadd wrote: Make sure you can collapse those ACLs down to something sensible for software processing before you go down that path! It's relatively easy to make a unified lookup tree of such structure, and even if you don't it's still as fast or faster than the current acl scheme. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: Refresh patterns and ACLs
2008/8/30 Henrik Nordstrom [EMAIL PROTECTED]: Make sure you can collapse those ACLs down to something sensible for software processing before you go down that path! It's relatively easy to make a unified lookup tree of such structure, and even if you don't it's still as fast or faster than the current acl scheme. Oh, I'm sure we could beat the current way we're using ACLs, the question is whether we can dramatically improve complicated ACL processing in the future. A big problem with the way we're inlining fast-path ACL lookups is that they suddenly become impossible to farm out to other threads. Adrian
Re: Refresh patterns and ACLs
Mark Nottingham wrote: One of the things that came up in Sydney briefly was whether the stale-while-revalidate and max-stale refresh_pattern options would be better expressed as ACLs. Taking this a bit further, could/should the same be true of the rest of the refresh_pattern options (and perhaps of the patterns themselves)? E.g., I have a user who wants to ignore-reload selectively based upon client IP; surely a good fit for an ACL if there ever were one... Just food for thought, Do you mean make a seperate tag? ie, send_stale [acl ...] Um, I woudn't do all of the refresh_pattern options over, some actually do match the logical idea of affecting the keep/replace state of a cached object. But the options that apply to active requests cached or not should be moved out to somewhere more understandable. Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE8
Re: Refresh patterns and ACLs
I vision a nested tree of matches (acl) and operators
(allow/deny/refresh_pattern/outgoing_ip/tos/no-cache/ignore-xxx/deny_info/logmessage/peergroup/...).
But it requires a different parser which is not single line oriented as
you can not express a tree on a single line in a meaningful manner..
request_access {
if [!]acls.. {
if [!]acls.. {
...
}
...
accept
}
deny
}
YES please..
I'm quite familiar with the JunOS ACL format and it resembes this
pretty closely, it's very flexible..
--
/kinkie
Re: Refresh patterns and ACLs
2008/8/29 Kinkie [EMAIL PROTECTED]: YES please.. I'm quite familiar with the JunOS ACL format and it resembes this pretty closely, it's very flexible.. Make sure you can collapse those ACLs down to something sensible for software processing before you go down that path! Adrian
Re: Refresh patterns and ACLs
I'm not convinced it's a great solution, but something like URISpace may be appropriate; http://www.w3.org/TR/urispace.html What's nice about this is that you buy some efficiency by walking down the tree, rather than evaluating a linear set of rules... Cheers, On 29/08/2008, at 10:38 AM, Adrian Chadd wrote: 2008/8/29 Kinkie [EMAIL PROTECTED]: YES please.. I'm quite familiar with the JunOS ACL format and it resembes this pretty closely, it's very flexible.. Make sure you can collapse those ACLs down to something sensible for software processing before you go down that path! Adrian -- Mark Nottingham [EMAIL PROTECTED]
Re: Refresh patterns and ACLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Nottingham wrote: I'm not convinced it's a great solution, but something like URISpace may be appropriate; http://www.w3.org/TR/urispace.html What's nice about this is that you buy some efficiency by walking down the tree, rather than evaluating a linear set of rules... Interesting spec: I can see uses for it elsewhere. A quick question, (since grubbing around shows you to be the author;): in section 3.3, Path Segments, the semantics of path match=foo are to match the next element in the current path, right? Rather than matching any random element (CSS style), or (for instance) the last element (which would be useful in particular for the empty pattern and filename globs). Is the spec frozen / dead, or could we suggest additions? E.g.: path any=archives and: path last= I can certainly put such extensions into another namespace, but they seem reasonably tightly connected to the existing first match semantics. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIt3qO+gerLs4ltQ4RAiQoAJ9VCfO8pSohOB8ayLli3LAeymMHswCgiqV7 zrG+JVzw78PRioZqTCyL8T4= =pQdp -END PGP SIGNATURE-
Refresh patterns and ACLs
One of the things that came up in Sydney briefly was whether the stale- while-revalidate and max-stale refresh_pattern options would be better expressed as ACLs. Taking this a bit further, could/should the same be true of the rest of the refresh_pattern options (and perhaps of the patterns themselves)? E.g., I have a user who wants to ignore-reload selectively based upon client IP; surely a good fit for an ACL if there ever were one... Just food for thought, -- Mark Nottingham [EMAIL PROTECTED]
