plugin / intra process communication system

[Florian Ludwig]

On Tue, 2010-02-16 at 19:20 +0100, Diez B. Roggisch wrote:
> 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.

Good point.

> 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.

> repoze.who and what are examples for such design.

repoze.who is new for me, it might not actually solve my problem here
but it looks interesting for other tasks :) Thanks.


> >> 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.

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.


> > [...]
> >
> > 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.

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".

Hope that clarifies my intentions a bit.

Thanks,
Florian


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


-- 
Florian Ludwig <dino at phidev.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/python-list/attachments/20100217/f4366180/attachment.sig>