Re: [Musickit-developer] Plugin architecture design

[Brian Willoughby]

Continuing the discussion...

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

You might want to define different suffixes for each kind of plugin, or  
different directories where they are stored.  IIRC, the application must  
manually load bundles - there is no automatic loading of all bundles in a  
directory unless coded that way - so segregating them will help the app know  
which kind of class to expect.  Then again, maybe it turns out it would be  
easier to have them all in the same place.  Note: there is only one principle  
class per bundle, so you'll need some method of obtaining the reader / writer / 
 
other classes from a bundle if they're all mixed together in the same place.   
If you have a scheme where the principle class lists the other classes  
(reader/writer/etc.) by type, then a given bundle could provide more than one  
type.

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

I think you should implement both as options.  Just like NXBrowser has three  
different potential types of delegates, and decides at runtime how to behave, I 
 
think it is important to allow for both kinds of file type discovery.  Some  
developers may prefer to avoid the challenge of writing a well-behaved magic  
detector, and will be satisfied with a finite list of extensions.  Others may  
be forced to detect files by content because existing files do not reliably  
have extensions (such as music files traded over the Internet rather than  
created locally).  Question: Does Mac OS X properly handle files which have no  
extension but have an HFS+ creator type instead?  Will the MK have to include  
additional code to support this, or is it automatic when using the system API  
for "extensions?"

[  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.
[
[  Thoughts?

I'm thinking of NEXTSTEP, but there are existing +(int)version and  
+setVersion:(int)aVersion class methods for identifying the version of a class. 
 
 These are intended for archiving classes correctly.  I should think they  
would be useful for versioning an API as well.  However, you would probably  
need #define values in the headers to identify major versions of the API (since 
 
some versions may never live outside test releases).  Also, your idea for a  
dictionary might still prove useful in identifying a collection of class  
versions in a particular release, since +version only identifies the version of 
 
a single class, not the entire API.

Brian Willoughby
Sound Consulting