Paul Everitt wrote:
> Just to see if I have the big picture right:
> 
> 1) We have a need to define a bunch of matching conditions, as well as 
> actions to take when those matches occur.
> 
> 2) We plan to separate the definition of the scenario matches from the 
> definition of actions.
> 
> 3) The former are called "page classes".  These page classes put a label 
> on when a scenario is matched.
> 
> 4) The latter are "rule sets".
> 
> 5) There is somewhat of an N:N relationship between scenarios and rule 
> sets.  A rule set can point to multiple page classes.  A scenario can 
> trigger rules from multiple rule sets.

I think this is right.  That is, you could have:

   <rules class="class1 class2">

And

   <match ... class="class3 class4" />

So in the first case, if either class1 and/or class2 was matched, then 
that rule set would be triggered.  In the second case, if the match was 
matched then both class3 and class4 would be added to the request.  So 
long as there is any intersection between the classes associated with a 
ruleset and the classes associated with a request, then the ruleset will 
be run.

>>  domain: a domain, with possible wildcard.
> 
> For Deliverance running as a proxy, Is this the forward domain or 
> reverse domain?

The request domain.  Nothing in Deliverance is really concerned with how 
the request is later dispatched.  (Also, it's becoming somewhat more 
common to preserve the Host header when proxying to other servers, at 
which point there's only one domain.)

>>  request-header: this would be "Header: match", like 
>> "X-Requested-With:  regex:(?i)xmlhttprequest".  The header name will 
>> be parsed out.  Maybe allow wildcards?  The part after : will be 
>> matched like path, except maybe a case-insensitive 
>> whitespace-normalized match as the default.  So "X-Requested-With: 
>> xmlhttprequest" would match a value of "XMLHttpRequest", but wouldn't 
>> match "XMLHttpRequest/foo"
>>
>>  response-header: just like request header, but the response.
> 
> I wonder if query string would need to be a match type.  This would 
> allow solving ?notheme as part of the general case.

This seems somewhat similar to SCRIPT_NAME/PATH_INFO.  Or... maybe 
easiest, just a separate query="..." match attribute.

> How about supporting a simple version and a complex version:
> 
> <rules match="my-page">
>   rule1
>   rule2
> </rules>
> 
> ...for the simple case and:
> 
> <rules>
>   <match>my-page</match>
>   <match>your-page</match>
>   <match>another-page</match>
> </rules>
> 
> ...for the complex case.
> 
> I'm really hoping that people don't have multiple-page-class-matching 
> scenarios until they are way, way, WAY into the koolaid.

In my experience you hit some of these things fairly quickly.

But, I'm not really sure what you are proposing.  The simple case:

   <rules match="my-page">

doesn't make sense to me.  You mean a path match?

>> then this would also have any standard rules.  This kind of overloads 
>> <match>, though I think in a way that's reasonably intuitive -- it 
>> feels the same, even though the implementation would be quite 
>> different. Though I'm not inclined to allow any other conditionals 
>> like <match path="..." /> in this context.
>>
>> Also, <theme href="..." /> would be allowed in this context, and the 
>> first matched class (I'd maintain classes in an order) would have its 
>> theme used.
> 
> <theme> is a child of what?  The N:N part has left me a bit bumfuzzled.

<theme> is a child of <rules>, or a top-level element to be inherited by 
all rules.

   Ian