CoreFoundation question
CoreFoundation question
- Subject: CoreFoundation question
- From: email@hidden
- Date: Tue, 28 Aug 2001 12:01:54 -0600
I know it's OT, but I wonder if anyone here can help...
I'm trying to learn how the CF PlugIn works, and I've read the docs that
Apple has provided, but the code example they provide is, I would argue,
oversimplified. It uses a previously-known URL to create the PlugIn,
then searches for factories and instantiates the iunknown.
I think that most folks who use a plug-in architecture (well, me,
anyway) want to define one or more types, then be able to dynamically
figure out what plugins provide factories for the type(s), without
having to have prior knowledge of how the plugins will be named. Am I
smoking crack here? So, does anyone know of a way to have the plugin
host dynamically locate candidate plugins?
An approach comes to my mind, but before I go down that path, has anyone
got some good suggestions?
The app could define a location (or some locations), say,
/Library/PlugIns and ~/Library/PlugIns, and enumerate all .plugin
packages found in those locations, instantiate the plugins, and then
look for factories for the types.
My conceptual problem with the approach is that every plugin-host app
must either provide its own subfolder in .../PlugIns (or somewhere
else), or else it will be instantiating CFPlugIns for plugins that
belong to unrelated apps, and no limiting (until memory is exhausted)
how many that might be.
I could find no information from Apple how they recommend partitioning
the plugin store.
The other concern that comes to my mind is that it seems not unlikely
that tools like web browsers and media players might share some plugin
types... so that it becomes preferable in that case to have all plugins
centrally located again, without special subdirectories for each one.
Has someone got a pointer to better Apple documentation? I've studied
http://developer.apple.com/techpubs/macosx/CoreFoundation/PluginServices/*
pretty thoroughly.
Thanks in advance,
--Tk!