plugin parsing code and acl lists

I've had a busy few months, and the flu as well (seems like it's going
around the squid developers!), but I'm putting some time into the
parsing code I was working on...
I have a choice to make: I can change
acl foo type data
acl foo type data
...
to
acl foo type
acl foo data
acl foo data

very very easily. (in fact it is easier than keeping the current
syntax). I think changing it will remove the possibility for users to
change type mid-acl.

Are there any preferences ?

Background: I've got a parse tree built, with run time registered types
a nodes. This means that modules can provide new configuration types
(for example a base64 encoded line,) and the parser will process those
via callbacks.

The parse tree means that add-in modules can use the built in parser
without needing their own parsing code. This should make modular
development easier.

I've still got a couple of key things to do:
* I've currently broken reconfiguring.
* I want to allow a hierarchy of types: global config types (can be
inserted into the parser tree anywhere, ACL config types (can only be
inserted into the acl sub-tree).
* I want to make parsing the options for things like per-fs-module
settings "automatic".. but until I finish off ACL handling I'm not
touching that. I think it's already coveredwith the code in place, but I
have tried yet :]
* ACL modularisation. this is in the generic modules branch after all
:]. Once I've got the above question settled, I'll be throwing out the
current acl mini-parser and utilising the generic code I've written.
That should then allow trivial insertion of new ACL types at runtime.

Rob
Received on Sat Mar 31 2001 - 16:30:29 MST