Re: Plugin interface desing?

FROM : Adam Knight
DATE : Fri Aug 04 20:53:40 2006

I actually saw that, downloaded it, and played with it.  It's a lot 
to take in, really.  Happen to have a sample app and code done up 
with that codebase?  I really liked the idea, but couldn't get around 
it.
--
Adam Knight
If you're not going to stop and appreciate the scenery, you're not 
going to
enjoy Myst.  The same thing applies on the Mac as well.  -- Rand Miller



On Aug 4, 2006, at 12:56 PM, Jesse Grosjean wrote:

>> I've read about how to make plugins, and I've written a demo app that
>> finds and calls a method on the plugin.  That much I have.  However,
>> what I can't seem to locate out there is a good document about how to
>> design a plugin interface for various problems.  That is, if I want
>> to hand processing off to a plugin, or have it extend the GUI in one
>> place, etc. as to what concepts could be employed in the protocol to
>> make that easiest.
>>
>> It's theory, and not proper for a discussion here, but if anyone has
>> some links or resources to follow up with, I'd love to see it.

>
> Please take a look at my Blocks plugin framework.
>
>     http://www.hogbaysoftware.com/project/blocks
>
> It's an open source framework for building "pure" plugin 
> architecture applications, and I'd love to have other people 
> building off if it. Currently all of my applications are built on 
> Blocks, and some people have written Blocks plugins to extend my 
> apps, but so far no one else has written any Blocks based 
> applications. If anyone is interested I'd be happy to get people 
> started.
>
> Blocks is a little different than standard plugin architectures, 
> because it's goal is to allow all application functionality to be 
> provided by plugin. Your main application become a boot loader for 
> the plugin framework, and all other functionality is provided by 
> plugins. It's similar (but much smaller and in objective-c) to the 
> Eclipse project plugin framework. To be able to do this effectively 
> plugins must be able to plug into other plugins. Basically each 
> plugin must define the points that it "extends" and may optionally 
> define points that other plugins can extends. Then the framework 
> puts the application together at runtime.
>
> Blocks has two parts. First there is the core framework (~7 classes 
> with no dependencies) for loading plugins. And then there is a set 
> of common plugins that will be useful for many apps. For example 
> there are plugins for software update functionality, crash 
> reporter, preference pane, shareware license...
>
> Anyway take a look, I'd love to get some other application 
> developers interested in this project.
>
> Jesse
>
>