[Mono-list] A Plugin and WebService Issue
Wed, 19 May 2004 23:01:54 -0500
The common approach on the net seems to be the following:
Define an interface, let's say IMyPlugin. this interface ideally should have a
method allowing you to supply a set of parameters needed to init the plugin's
main class, by say, passing params or something of the kind.
Then, you make all your plug-ins implement that interface.
You main app scans the plug-in folder, reflecting on the files found, looking
for assemblies that implement the interface. Once the assembly is found, you
add it to some internal data structure that keeps track of your plug-ins.
When ready to load your plug-in, you simply do a load across AppDomains. Please
note, that there has been some discussion on this list about potential issue
with Mono's cross-AppDomain loading/unloading. I didn't read into the
discussion, so I can't tell you whether it was an actual bug.
After the assembly is loaded, you can use reflection to bootstrap it via the
interface's method (cast assembly reference to the interface if you so wish).
>From there on, your plug-in will do the work. At the end, you can unload the
assembly and you are done.
This is an extremely simplistic idea and it bears much improvement. Tip: teach
your plug-ins to have an ability to tell the loading application about what
they require, in order to function.
I'm sorry folks, this is really OT, but since Pablo asked...
Quoting Pablo Fischer <email@example.com>:
> I would like to have some comments and suggestions about a issue.
> I am working in a Blog Client (mbloggy) that will work ONLY in SOAP (NO
> XMLRPC) for different CMS and Blogs (phpnuke, postnuke, jaws, etc, etc).
> To work with all these blogs I'm planning to use a 'plugin' system,
> based in assemblies, for example:
> If a developer wants the plugin for a CMS (like drupal), he can save his
> .dll plugin in ~./mbloggy/plugins and when mbloggy starts it will read
> default plugins (in /etc/mbloggy) and the user plugins. When mbloggy
> finds a new plugin it will be added to a 'drop down' (gtk#) so the user
> can use it.
> My problem?, yes, I don't know which is the best option:
> a) Use .dll assemblies as plugins. But, how to connect to each plugin
> from the front end?, exists a data type that can 'clone' another
> object?, so I can do something like this:
> Wrapper wrap = new Wrapper();
> wrap.Url = "http://www.foo.bar.com/foo.aspx?wsdl"
> So I can use the 'methods' of assemblie.dll in the wrap object?.
> b) Or use just one .dll and let the developers to 'develop' just the
> WebService (server)?, So I can just work like this:
> Client c = new Client();
> c.Url = "http://www.foo.bar.com/foo.aspx?wsdl"
> Which is the best option? and where can I find more information for the
> best option?.
> Pablo Fischer Sandoval (pablo [arroba/at] pablo.com.mx)
> Fingerprint: 5973 0F10 543F 54AE 1E41 EC81 0840 A10A 74A4 E5C0