Re: external acl cache level

mån 2006-05-22 klockan 11:46 -0300 skrev Gonzalo Arana:

> Reordering and combining perhaps? Allowing combining would raise the
> number of cached entries invalidations from N-2 to (2**N)-2 (I am not
> counting current reply as an invalidation).

The big problem is the lookup, which we want to keep quick..

Invalidation is not strictly needed, depending on the lookup order. As
long as the lookup gives less detail higher priority there is no
conflict (only unneeded entries in the extacl cache).

To be able to make sane lookup structures it is very beneficial if the
data can be structured in a path like structure. This worked out quite
okay except that there is acl types where the acl arguments (the data in
the acl statement) is more important than some request details
(external_acl_type format tags)...

> The format tag should expand to some string we are sure is not present
> in any other tags, which is something difficult to assure since we
> have %{Header:member} tag. Adding 'level' support for external acl
> cache implies the request/reply pair need some higher level structure
> (say XML, or HTTP-alike), unless I am missing something.

I am not sure I see the problem you refer to. Can you eloberate a bit on
what kind of problem you see?

Draft patch attached. This patch adds %DATA expanding into the acl
arguments (and %ACL expanding into the acl name for completeness).

Problem: %DATA have a slight problem with whitespace characters if the
helper is to handle arguments with whitespace AND multiple arguments in
the same acl type.. as currently written they both looks the same in the
%DATA expansion.. (a space character, appropriately encoded per the
helper protocol).

Which reminds me.. external acl helper protocol should be switched by
detault to the 3.0 format for 2.6. The "shell escaped" format used in
2.5 was a bit of mistake.. (looks pleasing to humans, but is quite ugly
to computers)

The "level" adds structure to the requests by allowing it to be
structured in a path like manner when needed by introducing the level
separators in the request format.

  %DST %| %PATH

Problems:

The helper is assumed to know the key levels defined in
external_acl_type. These are not reflected in the request data. Not sure
this actually is a problem, but results may be odd if the admin
configures his external_acl_type differently than expected by the
helper..

With the lack of %DATA above this approach fails if the data from the
acl is more important than some request details.

Another approach would be to mark the arguments per their key detail
level. With this approach %DATA is not needed as the request parameters
do not need to be sorted on their detail level and could even be
extended into alternate priorities. However it shares the first problem
above (if it is a problem..).

The key detail level markup provides the most flexible solution ofthe .
But may be too complex for the admin.. but I suppose nothing stops using
a combination to provide the best of both as the first is a subset of
the detail level markup, with the level increasing per level marker..

Regards
Henrik