> Anyway, is it just a proposal. It is very flexible, but another proposal
> could easily make better sense. It would be nice to have some properties
> with names and/or values that are more explanatory of the configured
> behavior but set the match/nomatch values to correct Filter values.
I did some quick analysis of the various combinations. If we allow a value
to be set for matches and nomatches, that is 9 possible combinations. Of
that 9, the ones that have the same value for match/nomatch aren't very
interesting (DENY/DENY is the equivalent of deny all). But, interestingly,
there are only 4 combinations that make sense for filter chains because one
of the two values is set to NEUTRAL:
match value / nomatch value
ACCEPT / NEUTRAL (equivalent of OR with a denyall at end of chain)
DENY / NEUTRAL (? partial OR ?)
NEUTRAL / ACCEPT (? partial AND ?)
NEUTRAL / DENY (equivalend to AND)
the other two combinations are:
match value / nomatch value
ACCEPT / DENY (?accept on match?)
DENY / ACCEPT (?deny on match?)
So, my questions are:
1) Do you think that exposing the match/nomatch return values directly will
be too confusing? Should we come up with "names" for the various
combinations that will help users know what they are configuring?
2) Is there another mechanism/design that could be used to better expose the
underlying feature of filters/filter chains?
-Mark
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
