On Mon, 6 Feb 2006, [ISO-8859-1] Ask Bj?rn Hansen wrote:

On Feb 5, 2006, at 10:55 AM, Charlie Brady wrote:

I wish to have different configurations for different connecting clients. And I'd like to have finer grained control than just whether they are permitted to relay or not. I've roughed out a plugin for doing that, and I'd appreciate some feedback.

That's really neat -- even I had not thought of that.  :-)

Even you, eh? :-)

If you changed the magic file to be a directory name you could make the plugin be a config plugin and have it do more configuration by peer.

I don't see how it could do more configuration by peer, because I think my proposal is complete - you could have different configuration for every peer IP address if you had enough disk space and patience to create the configs. I don't quite understand your proposal, as I can't find much on config plugins and why I might want them.

It should be possible to modify the list of plugins on the fly (without having to reload them all the time).

The first way I thought of approaching the issue was to manipulate the hook table during the connect hook. But then I worked out that it would be easy to separate the compile and load actions. As I said, this does somewhat increase the per client load, but it adds a lot in flexibility, and only if you want it. It also allows you to have different plugin configurations in different clients - not just a different set of plugins, but different plugin parameters.

[reordered] What would you need to change in the core to make it easier to make your plugin?

An API to compile and not load a plugin would have been handy. As it is I'm making assumptions about internal namespace issues. Being able to selectively hook and unhook plugins might also be useful. An API to compile and load, but not hook a plugin would also deal somewhat with the efficiency issues.

The IP search algorithm to find a best matching config BTW comes from Dan Bernstein, via Gerrit Pape's ipsvd package. I don't know if it is commonly used elsewhere. I originally considered having those files contain content that was specific to the peers plugin, but it was just easier (and suitably powerful) to run _load_plugins().

---
Charlie

Reply via email to