I can be dense. Do I understand correctly that
- You have an application that ideally should run continually.
- It accepts plugins that provide one or more classes.
- Those classes must at least observe a protocol; otherwise there would be no
sensible way to use them.
- They must have unique names.
- As is typical of ObjC plugins, the classes are packaged in a dynamic library;
and as is typical, the library is wrapped in a package directory, which your
application has registered with Launch Services as a package, of a certain type
and edit/view/associate relationship to your application. I'm sure this is so
in your case, as plugins typically need to carry resource files.
- If a package, the plugin might carry an Info.plist file — plugins commonly do.
- You mean to load and unload plugins dynamically, as they appear and disappear
in a designated directory, without interrupting the application.
Do I follow you so far? If so, I have some comments.
You can't unscramble the egg: Dynamically-loaded classes can be loaded any time
you like, but they cannot be reloaded or unloaded. Surely you know this; surely
I misunderstand (or am behind the times).
If you are (practically) committed to a package structure with an Info.plist,
why can't you add an <array> key listing the names of the provided classes? Or
for that matter, a text file containing the names? That's one of the things
NSBundle is for. It is a universal practice. "Just works" is a great ideal, but
one can expect someone who knows how to build a dynamic library to understand
such things.
The declared classes might not implement the required methods, but that's easy
and safe to detect once they are loaded. If you must reject, your duty ends
when you log the problem and put up an alert.
Am I missing something?
— F
> On Dec 15, 2014, at 11:59 AM, Maxthon Chan <m...@maxchan.info> wrote:
>
> What I am doing here is to determine a format handling class based on file
> extension. I want to achieve a drop-to-plugin-folder-and-it-will-work effect
> and allow one plugin to include multiple format handling classes. Also since
> I am creating an open system I don’t want to require other plugin writers to
> register their classes, instead the main code shall discover plugins on its
> own.
>
> This means that the main code will not be able to call any plugin classes
> methods so +initialize never get called. Also your approach means that the
> main code will hold a strong reference to the plugin code which prevents
> plugin unloading.
>
> Class walking may be fragile, but it is fragile enough to allow plugins to
> come and go easily without having to restart the main code.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
