Re: Providing application resources to a Plugin
Re: Providing application resources to a Plugin
- Subject: Re: Providing application resources to a Plugin
- From: "Eric Czarny" <email@hidden>
- Date: Tue, 22 Aug 2006 13:52:57 -0400
I was a little confused at first when it came to loading an NSBundle into an
application... Meaning, I wasn't sure if it was brought into the
application's space. Fortunately Kirk Kerekes sent me an email that cleared
things up.
The following is my interpretation, feel free to correct me if I am wrong.
Basically, for the sake of others looking for a solution (and for my own
sake in the future, in case I need to find this concept again), anything
available within an application's space is also available within the space
of the plugin... So, when it comes to developing a plugin architecture, the
only decision that really needs to be made is what internal functionality of
the application should be documented and opened to the public. It really
doesn't matter how you open up that functionality (albeit a simple protocol,
or a more complicated framework) as long as plugin developers know what they
have access to.
In fact, it sounds like you don't have to do any of that. You could simply
write code within a plugin as if it were in the application itelf. Turn off
the warnings complaining about missing symbols, etc, and link it into the
application. Everything within that application should become available to
the plugin, as it appears the Objective-C runtime takes care of it. Of
course this opens up the possiblity of duplicate symbols.
All of this really makes the task of developing a plugin architecture an
open-ended one. You can design it however you want. It just depends on how
robust of an architecture you want.
As of now this is all that I have. While I continue to make decisions on a
plugin archtiecture for my project I will be more than happy to post updates
here (if any happen to be interested).
Cheers,
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden