Re: plugin parsing code and acl lists + CVS

----- Original Message -----
From: "Roger Venning" <r.venning@telstra.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>;
<squid-dev@squid-cache.org>
Sent: Monday, April 02, 2001 9:14 AM
Subject: Re: plugin parsing code and acl lists + CVS

>
> Quick question: what kind of type / data are we considering here? If
you
> can specify
> things like "acl bar int 1234" & "acl bar ipaddr 1.2.3.4", I want this
&
> I want it now!
> But I'm guessing this is not what you mean.

Uhmm, I'm not sure what you mean!

Perhaps an ACL-specific example:

you want to write an ACL to check the TOS bit of the incoming data
stream (presumably set by an upstream provider).

Currently you need to
* Define a new acl type in acl.c
* write parsing code for the acl type if doesn't fit into one of the
existing ACL parsers (int/time/ip/wordlist/splaytree/eol/AS/cache_dir
etc from top of head)
* write matching coded for the acl type.
* update cf.data.pre with instructions on use
* possibly update configure.in with ne portability checks
* #define everything carefully to allow the code to be --enabled

Under the generic_module structure, you can still do that. Or:
you create a new module called TOS_ACL (or whatever)
in your module register function you
*register one more more ACL types - say "reply_tos" and "source_tos"
*register any new parsers that you require (that aren't inbuilt as
above)

in your ACL _instance (haven't named it yet) function for each acl type
* register the parser name (reply_tos or source_tos) with the parser
type(s) you accept. (This implies that single acls may at their
discretion accept multiple sub-entries. They can (this might be useful
if you need multiple different data types to configure the acl
properly.)

in the source file you
* write code as before to match your acl
* if you provide a new parser type, write it's parse/free & dump code(as
above)

and finally
* update configure.in if you have new portablility checks.

Note: the benefits here are:
* simple use of parsing functionality.
* no need to #define your code or add --enable options to configure.in -
the user configures with --enable-modules="acl_tos"

Their will also be the potential for half-and-half, using the parsing
code without being split into a module.

Having written all that, I'm guess that the TOS acl needs more than a
single entry to configure?

If so there are two basic approaches: the current squid approach -
define two acl types, and the user has to test them both
acl bar1 int 1234
acl bar2 ip 1.2.3.4
http_reply_access deny bar1 bar2

the second option would be to add two parser nodes, one for each option,
under the acl type node:
acl bar tos tosvalue 1234
acl bar tos tosip 1.2.3.4

Doing that is 2 lines of code [
RegisterParserName(parentName, "tosvalue", ParserTypeByName("int"),
&acldata->tosvalue, NULL, NULL, NULL);
RegisterParserName(parentName, "tosip", ParserTypeByName("ip"),
&acldata->tosip, NULL, NULL, NULL);

After that the parser will see "acl bar tos tosvalue" and automatically
chain to the int parsing code.

Is that what you're looking for?

Rob

> Second thing: I get this from CVS
>
> cvs server: Up-to-date check failed for `src/acl.c'
> cvs server: Up-to-date check failed for `src/protos.h'
> cvs server: Up-to-date check failed for `src/structs.h'
> cvs [server aborted]: correct above errors first!
> cvs commit: saving log message in /tmp/cvsJdlZXt
>
> when trying to commit my branch (that I first committed mistakenly
> to source forge head, then mkcvsbranch rvenning_tosacl, then
> cvs commit again). Any ideas how to fix?

run cvs -z9 update - that will merge in the new changes to acl.c,
protos.h & structs.h. It sounds like there was some confusion initally -
I suggest copying those three files to a safe location first - just in
case.

> Roger.
>
> Robert Collins wrote:
>
> > ----- Original Message -----
> > From: "Henrik Nordstrom" <hno@hem.passagen.se>
> > To: "Robert Collins" <robert.collins@itdomain.com.au>
> > Cc: <squid-dev@squid-cache.org>
> > Sent: Sunday, April 01, 2001 10:42 AM
> > Subject: Re: plugin parsing code and acl lists
> >
> >
> >> Robert Collins wrote:
> >>
> >>> I have a choice to make: I can change
> >>> acl foo type data
> >>> acl foo type data
> >>> ...
> >>> to
> >>> acl foo type
> >>> acl foo data
> >>
> >> ...
> >>
> >>> Are there any preferences ?
> >>
> >> My preference is to have the type always listed, and barf loudly if
> >
> > the
> >
> >> user is stupid and does not know what he/she is doing. I think it
is
> >> less error prone that way, and surely less confusing when seeing
> >
> > config
> >
> >> fragments..
> >
> >
> > Ok. Any other input?
> >
> >> Also it allows for things like this without worry:
> >>
> >> #acl foo type data
> >> acl foo type moredata
> >> acl foo type ...
> >> #acl foo type otherdata
> >> acl foo type evenmoredata
> >
> >
> > Which would be
> > acl foo type
> > acl foo data
> > acl foo evenmoredata
> > ac foo evenmoremoredata
> >
> > Rob
> >
> >> /Henrik
> >>
> >>
>
>
> --
> -------------------------------------------------------------
> Roger Venning \ Do not go gentle into that good night
> Melbourne \ Rage, rage against the dying of the light.
> Australia <r.venning@bipond.com> Dylan Thomas
>
>
>
Received on Sun Apr 01 2001 - 03:35:15 MDT