Re: Plugin architecture design

[e.sammer]

Stephen Brandon wrote:
> So for score reading, I would envisage that when the MK loads a plugin, it 
> either calls a method on the plugin's principal class that explicitly asks 
> what sort of files it opens, or expects the plugin to do a callback to 
> register itself as a reader.

From what you describe, it sounds like you want to use NSBundle for 
something like this. You could register bundles easily by requesting the 
principal class which implements a defined MK protocol. After loading 
the bundle, I would imagine you would just do something like:

pluginController = [[[myBundle principalClass] alloc] init];
if ([pluginController conformsToProtocol:@protocol(MusicKitPlugin)]) {
  [pluginController setDelegate:self];
  [self addPlugin:pluginController];
}

[pluginController release];

Then, the plugin controller (the NSBundle principal class) would have a 
delegate that could be used as part of the "callback metaphor". Also, 
you could use the delegate to allow / disallow actions by the plugin the 
same way NSWindow allows / disallows closing or resizing events.

> Versioning
> ------------
> I have also thought about the need for versioning the API - if the API 
> evolves we don't want to break old plugins. So perhaps we publish an API in 
> the MK with textual/numeric tags, which the plugin can return in a dictionary 
> when loaded, corresponding to which APIs it supports.

I would think that the best way to support versioning of the protocol or 
plugin api would be to have a protocol method the plugin would have to 
implement that returns the version of the api like:

@protocol MusicKitPlugin
+ (NSString*)protocolVersion;
@end

This way, the plugin could do things like forwardInvocation if it wants 
to dynamically "alter" it's protocol version. Another idea might be to 
query the delegate for which protocol version it wants and go from there.

Of course, these are just some ideas... hope this helps.

--
e.sammer <eric@linuxstep.org>
http://www.linuxstep.org