plugin / intra process communication system

Diez B. Roggisch deets at nospam.web.de
Tue Feb 16 13:20:03 EST 2010


Am 15.02.10 23:12, schrieb Florian Ludwig:
> On Sun, 2010-02-14 at 18:47 +0100, Diez B. Roggisch wrote:
>>> Here there problem with the trac (and other plugin systems I've
>> seen)
>>> approach:
>>>
>>> You need to define something like:
>>> |
>>> | class IAuthPlugin(Interface): [...]
>>> |
>>> in your blog software.
>>
>> Why? Any reason you can't define it in a separate package the
>> blog-software depends on, as well as your wiki?
>
> That's actually my point - most plugin systems I've seen, like the one
> trac uses, are not encouraging you to do so. Having a module that just
> defines an Interface is kind of weird - and in the real world no one is
> doing it.

Just because nobody doesn't do it doesn't mean it's not desirable. IMHO 
the ones using interfaces usually immediatly implement them for some 
cases - so you actually get the interface for you authentication 
framework, and also implement an OpenID plugin for it. And this forms 
one package. Then you can add new packages that implement other things.

repoze.who and what are examples for such design.


>
>> And then of course, this is not really needed. In Python, behavior
>> counts, not type-information. So you can get away without any explicit
>> declared interface. You might chose to not do that, for aestetic
>> reasons, or better documentation. But you aren't forced.
>
> Actually some plugin-systems in python do force you and they check if
> your "implementation" comply with the "interface".

I didn't say nobody does it, I just said it isn't needed to get a 
working plugin system. If you don't want to have a separate package 
*and* don't want to pull in any unused code, this is pretty much your 
only option.

> Here is one solution I came up with. Based on the earlier example:
>>>      Lets say you program a wiki and like to allow different kind of
>>>      authentications. So you create two plugins (for example one for
>>>      OpenID and one for Shibboleth).
>>>
>>>       Some time later you feel like reinventing the wheel again and
>>>       you program a blog. Again you like to allow different ways of
>>>       authentication and you already wrote plugins for exactly the
>>>        same for your wiki, right?
>
> auth_openid.py - providing the authentication service
> http://dpaste.com/hold/159619/
>
> wiki.py - providing the wiki
> http://dpaste.com/hold/159634/
>
> Now putting both together:
>
>> import pbus
>>
>> import wiki
>> import auth_openid
>> # or: import auth_shibboleth
>>
>> pbus.get("wiki").run()
>
> No interface definitions.
>
>
> What do you think? Any obvious pitfalls (besides reinventing something)?

I don't know what pbus is supposed to do. Nor how it's laid out on a 
python package level.

Diez



More information about the Python-list mailing list