Curtis Jackson <[EMAIL PROTECTED]> wrote:
> I want to give plug-in developers a .o that is the shared library setup
> with dispatch table, etc., and a .h, and allow them to build plug-ins that
> link to the .o and are required to have an init routine of a particular
> name (said name to be compiled into the .o I give them). Then I can
> dynamically load and unload code modules as shared libraries.
Hmm... it's not 100% obvious that you're gaining an awful lot by making
them shared libraries, but okay...
> The problem I see potentially is that every one of these plug-ins will have
> the same creator, type, and name. What is a good approach that will allow
> me to enumerate the libraries in my master program and differentiate them?
If your plug-in developers are doing the link step themselves, then they
are also doing the build-prc step themselves, so they get to set the type,
creator, and name themselves.
The database name is the primary key for distinguishing all databases,
so the plugins all need to have different names, so you should tell your
plug-in developers to give their plugin a name which is unique to their
particular plugin.
You then have the choice of fixing either the type or the creator id of
the plugins (or both). Specifically you could say something like one of
the following:
* "Plugins must have a type of 'CJPI' [1] and a creator id registered by
the plugin author."
You enumerate them with DmGetNextDatabateByTypeCreator ('CJPI', *).
Each plugin has a distinct type/creator pair to give to SysLibLoad.
They all appear separately in the Launcher delete and info dialogs.
This is how HackMaster arranges 'HACK's.
* "Plugins must have a creator id of 'CJPI' and a distinct type chosen
by the plugin author."
You enumerate them with DmGetNextDatabateByTypeCreator (*, 'CJPI')
(avoiding any other non-plugin databases with your creator id).
Each plugin has a distinct type/creator pair to give to SysLibLoad.
I'm not sure how they appear in the Launcher; unless 'CJPI' is the same
as your master app's creator id, in which case they'll be added into the
master app's accounting -- this is tidy, but you'll probably want to write
your own plugin management (delete/beam/etc) UI.
It's a little fuzzy how to arrange for the third party plugin developers
to choose *distinct* types.
* "Plugins must have a type of 'libr' (or whatever -- something fixed) and
a creator id of 'CJPI'."
You enumerate them with DmGetNextDatabateByTypeCreator ('libr', 'CJPI').
There are the same tradeoffs in the Launcher as the previous option.
You can't use SysLibLoad because the plugins don't have distinct
type/creator pairs. So you need to open the database and lock the
code resource yourself and use SysLibInstall. At this point, you're
doing all the work yourself so you might as well not use shared libraries
at all, just a manual plugin arrangement.
Those are probably most of the tradeoffs. Danny Epstein and I were
talking about this over lunch: I think I still don't much like the idea
of varying the types, but basically "it depends". :-)
Did I cover the bases, Danny?
John
[1] "Curtis Jackson Plug In" :-) -- or whatever -- just some
not-all-lowercase type or creator that you choose (and register).
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
