plugin / intra process communication system

[Diez B. Roggisch]

>> 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.
>
> So if I want to implement another authentication mechanism but doesn't
> use any of the auth-frameworks code you mentioned you still would depend
> on it.

This depends on your definition of depending... (pun intended).

Sure, the code floats around. But it isn't *used* by your application. 
Why do you bother so much?

>> 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.
>
> Do you know somebody/some project/system/... who does it?
>
> Pulling unused code I definitely want to avoid so I probably will stay
> with this way.

Well, it's simply duck-typing, so you find it all over the place. Out of 
my head I only know about e.g. TurboMail, that allows you to specify 
plugins via pkg_resources entry points & simply uses them.

> Its "the plugin system", connecting "service providers" (plugins) and
> "service users". In my example the "users" also are providers at the
> same time, the service "auth", provides the service "wiki".

So it's hypothetical?

To summarize my point again: if you want explicit type-checking or 
zope-style interface implementation, but don't want any code that 
implements this (at least not imported) - you need an explicit package. 
If you don't want this, use duck-typing.

>
> PS I removed you (diez) from the TO list as that bounced. Probably
>     related to the (not existing?) domain nospam.web.de

I post through NNTP, and the email is obfuscated for the obvious reasons.