Plugin architecture design

[Stephen Brandon]

Hi all,

Before I plow in and create some sort of plugin scheme for the MusicKit I 
thought I should ask around and see if any of you guys have any tips for 
doing this.

The code for the new MusicXML reader is now working well for most basic 
parameters, and I want to move it from being an application to being a plugin 
to the MusicKit.

There are lots of different kinds of plugins that one might write for the MK. 
There's score reading (like this one), writing, and no doubt others.

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.

eg the MK could have a class method like this

+ registerClass:(Class)c asReaderFor:(NSArray*)fileSuffixes

An alternative might be that plugins simply register themselves without 
particular suffixes, in which case the MK hands around a file to each 
registered reader in turn, until one decides to accept it

eg the MK could have a class method like this:

+registerClassAsReader:(Class)c
{[readers addClass:c]}

+readFile:(NSString*)f
{ for (i = 0 ; i < [readers count]; i++)
    if ((score = [[readers objectAtIndex:i] readScorefile:f])
        return score;
}

The disadvantage with the first method is that the plugin has to decide on a 
bunch of fixed suffixes, which then ties it down a bit more to dealing with 
actual files instead of NSData/NSString encapsulated files. For the second, 
plugins have to be well behaved when trying to read files of unknown origin, 
and know when to bail out instead of throwing exceptions or crashing.

Thoughts?

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.

eg the principal class of all plugins must implement:
+ (NSDictionary*)MKPluginAPI

which returns a dictionary:
(key): @"scoreloading" (object): dictionary of versions and classes eg 
@"1"=>MyPluginClass, @"2"=>MyAlternativeClassForVersion2
(key): @"scorewriting" (object): dict of versions and classes for writing

Thoughts?

I'm going to be writing this over the next day or 2, so any feedback will be 
greatly appreciated.

Cheers,
Stephen Brandon
stephen@brandonitconsulting.co.uk