Re: How can a plug-in bundle get access to its own resources?

[Benjamin Miller]

On 10 Nov 2009, at 11:45, Motti Shneor wrote:

This may seem a silly question, but I cannot find any decent way for  
my Plug-In bundle code to access its own resources!


... snip ...

Is there a way out? Is there any trick, or technique to work around  
this bizarre deficiency of the Bundle mechanism?




[[NSBundle bundleForClass] self class] ?


Benjamin
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Benjamin Miller]

On 10 Nov 2009, at 11:45, Motti Shneor wrote:

Is there a way out? Is there any trick, or technique to work around  
this bizarre deficiency of the Bundle mechanism?


That should have been: [NSBundle bundleForClass:[self class]]

Benjamin
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Kiel Gillard]

On 10/11/2009, at 10:51 PM, Benjamin Miller wrote:


On 10 Nov 2009, at 11:45, Motti Shneor wrote:

This may seem a silly question, but I cannot find any decent way  
for my Plug-In bundle code to access its own resources!


... snip ...

Is there a way out? Is there any trick, or technique to work around  
this bizarre deficiency of the Bundle mechanism?




[[NSBundle bundleForClass] self class] ?


More correctly:

NSBundle *pluginBundle = [NSBundle bundleForClass:[self class]];



Then you can access the paths of the resources associated with that  
bundle using the usual methods identified in the reference given above.


Kiel
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Motti Shneor]

Thanks guys, but you may have not read all my message ---

The [NSBundle bundleForClass:[self class]]; 

is unusable for me, because I have many plugins that build from the same code, 
and export the same class (of course --- the same class name).

Obj-C has no name-spaces, and so, If you load 2 such plugins, and use the 
[NSBundle bundleForClass:[self class]] in each of them independently --- you'll 
get erroneous answers! both of them will return the same bundle although they 
come from different bundles.

This is hardly a system "bug" because there are no namespaces, and for the same 
class name there is only one bundle.

Any other ideas?


On 10/11/2009, at 13:57, Kiel Gillard wrote:

> On 10/11/2009, at 10:51 PM, Benjamin Miller wrote:
> 
>> On 10 Nov 2009, at 11:45, Motti Shneor wrote:
>> 
>>> This may seem a silly question, but I cannot find any decent way  
>>> for my Plug-In bundle code to access its own resources!
>>> 
>>> ... snip ...
>>> 
>>> Is there a way out? Is there any trick, or technique to work around  
>>> this bizarre deficiency of the Bundle mechanism?
>> 
>> 
>> 
>> [[NSBundle bundleForClass] self class] ?
> 
> More correctly:
> 
> NSBundle *pluginBundle = [NSBundle bundleForClass:[self class]];
>   
>> 
> 
> Then you can access the paths of the resources associated with that  
> bundle using the usual methods identified in the reference given above.
> 
> Kiel

Motti Shneor
--
Senior Software Engineer
Waves Audio ltd.

Phone: +972-3-6094415
Mobile: +972-54-4470730
[mailto: mot...@waves.com]



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Mike Abdullah]

On 10 Nov 2009, at 12:59, Motti Shneor wrote:


Thanks guys, but you may have not read all my message ---

The [NSBundle bundleForClass:[self class]];

is unusable for me, because I have many plugins that build from the  
same code, and export the same class (of course --- the same class  
name).


Obj-C has no name-spaces, and so, If you load 2 such plugins, and  
use the [NSBundle bundleForClass:[self class]] in each of them  
independently --- you'll get erroneous answers! both of them will  
return the same bundle although they come from different bundles.


This is hardly a system "bug" because there are no namespaces, and  
for the same class name there is only one bundle.


Any other ideas?


Yes, build your plug-ins with different class names. Doing otherwise  
will little the console with warnings. It's not too hard to setup a  
macro that takes the common classname and generates a unique one for  
each plug-in.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Alastair Houghton]

On 10 Nov 2009, at 12:59, Motti Shneor wrote:

> is unusable for me, because I have many plugins that build from the same 
> code, and export the same class (of course --- the same class name).

That's your mistake.  You shouldn't do that.  Class names must be unique within 
a process, otherwise you could cause yourself all kinds of pain.

Kind regards,

Alastair.

-- 
http://alastairs-place.net



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Douglas Davidson]

On Nov 10, 2009, at 4:59 AM, Motti Shneor wrote:


Thanks guys, but you may have not read all my message ---

The [NSBundle bundleForClass:[self class]];

is unusable for me, because I have many plugins that build from the  
same code, and export the same class (of course --- the same class  
name).


Obj-C has no name-spaces, and so, If you load 2 such plugins, and  
use the [NSBundle bundleForClass:[self class]] in each of them  
independently --- you'll get erroneous answers! both of them will  
return the same bundle although they come from different bundles.


This is hardly a system "bug" because there are no namespaces, and  
for the same class name there is only one bundle.


As others have said, don't do this.  However, to answer your question,  
the other way to locate your bundle is via bundleWithIdentifier:.


Douglas Davidson

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Michael Ash]

On Tue, Nov 10, 2009 at 6:57 AM, Kiel Gillard  wrote:
> On 10/11/2009, at 10:51 PM, Benjamin Miller wrote:
>
>> On 10 Nov 2009, at 11:45, Motti Shneor wrote:
>>
>>> This may seem a silly question, but I cannot find any decent way for my
>>> Plug-In bundle code to access its own resources!
>>>
>>> ... snip ...
>>>
>>> Is there a way out? Is there any trick, or technique to work around this
>>> bizarre deficiency of the Bundle mechanism?
>>
>>
>>
>> [[NSBundle bundleForClass] self class] ?
>
> More correctly:
>
> NSBundle *pluginBundle = [NSBundle bundleForClass:[self class]];
> 
>
> Then you can access the paths of the resources associated with that bundle
> using the usual methods identified in the reference given above.

It's best to avoid [self class] for things like this, because your
class can be subclassed, causing bundleForClass: to give you the wrong
answer. You might even get the wrong answer if the subclass is one of
those fun dynamically-created subclasses that you get when using KVO.

To get the bundle that you're writing code for, either provide an
explicit class ([NSBundle bundleForClass:[MyFoo class]]) or use
bundleWithIdentifier:.

Mike
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Motti Shneor]

Thanks, but the bundleWithIdentifier has its own problems.

1. The identifier is (as far as i know) accessible only from the bundle itself, 
which I don't have! I'm circling around here, without access to my own 
resources!  Must I hard-code the bundle identifier as a string constant within 
each of my plug-ins?

2. Even if I DO follow this rule, how can I manage to distinguish between two 
bundles that include the same plug-in but from different versions?

They have the same class, and the same identifier


Really, Isn't there a way for a library (dll, dylib framework etc) to know what 
is its containing bundle?


On 10/11/2009, at 19:42, Douglas Davidson wrote:

> 
> On Nov 10, 2009, at 4:59 AM, Motti Shneor wrote:
> 
>> Thanks guys, but you may have not read all my message ---
>> 
>> The [NSBundle bundleForClass:[self class]];
>> 
>> is unusable for me, because I have many plugins that build from the  
>> same code, and export the same class (of course --- the same class  
>> name).
>> 
>> Obj-C has no name-spaces, and so, If you load 2 such plugins, and  
>> use the [NSBundle bundleForClass:[self class]] in each of them  
>> independently --- you'll get erroneous answers! both of them will  
>> return the same bundle although they come from different bundles.
>> 
>> This is hardly a system "bug" because there are no namespaces, and  
>> for the same class name there is only one bundle.
> 
> As others have said, don't do this.  However, to answer your question,  
> the other way to locate your bundle is via bundleWithIdentifier:.
> 
> Douglas Davidson
> 

Motti Shneor
--
Senior Software Engineer
Waves Audio ltd.

Phone: +972-3-6094415
Mobile: +972-54-4470730
[mailto: mot...@waves.com]



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Mike Abdullah]

On 15 Nov 2009, at 11:36 AM, Motti Shneor  wrote:


Thanks, but the bundleWithIdentifier has its own problems.

1. The identifier is (as far as i know) accessible only from the  
bundle itself, which I don't have! I'm circling around here, without  
access to my own resources!  Must I hard-code the bundle identifier  
as a string constant within each of my plug-ins?


If you want to use that method, yes


2. Even if I DO follow this rule, how can I manage to distinguish  
between two bundles that include the same plug-in but from different  
versions?


They have the same class, and the same identifier


Really, Isn't there a way for a library (dll, dylib framework etc)  
to know what is its containing bundle?


As already explained to you, having the same class loaded twice is a  
really bad idea. You have an API that does exactly what you want  
(bundleForClass:) — now fix your code not to re-use class names



On 10/11/2009, at 19:42, Douglas Davidson wrote:



On Nov 10, 2009, at 4:59 AM, Motti Shneor wrote:


Thanks guys, but you may have not read all my message ---

The [NSBundle bundleForClass:[self class]];

is unusable for me, because I have many plugins that build from the
same code, and export the same class (of course --- the same class
name).

Obj-C has no name-spaces, and so, If you load 2 such plugins, and
use the [NSBundle bundleForClass:[self class]] in each of them
independently --- you'll get erroneous answers! both of them will
return the same bundle although they come from different bundles.

This is hardly a system "bug" because there are no namespaces, and
for the same class name there is only one bundle.


As others have said, don't do this.  However, to answer your  
question,

the other way to locate your bundle is via bundleWithIdentifier:.

Douglas Davidson



Motti Shneor
--
Senior Software Engineer
Waves Audio ltd.

Phone: +972-3-6094415
Mobile: +972-54-4470730
[mailto: mot...@waves.com]



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net

This email sent to cocoa...@mikeabdullah.net

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Steve Christensen]

As has been pointed out several times, it's a really bad idea to have  
the same-named class in multiple plugins. The Objective-C runtime will  
load the first class instance it finds (in your case, in the first- 
loaded plugin). For all other plugins, when the class is referenced,  
that first class instance is used, so calling [NSBundle bundleForClass: 
[self class]] will cause it to return the bundle for that first  
plugin, no matter which plugin is asking. This answers your question  
about code knowing its containing bundle. You made an assumption about  
where the plug-in's code was loaded that turned out to be incorrect.


If you want to use the same class code for each plug-in, I would  
suggest that you use a #define to rename the plug-in class at build  
time, and add a per-target definition containing a unique class name.  
Then your common class would be renamed automatically for each target.  
If you have to specify the plugin class in, say, your Info.plist, you  
could use the same build definition.


@interface PLUGIN_CLASS_NAME
...
@end


@implementation PLUGIN_CLASS_NAME
...
@end

The benefit of going with this model is that you still maintain a  
single code base for all of your plugins, even though the class is  
renamed on a per-plugin basis; you eliminate the "which plugin am I"  
problem you're running into now; and you don't have to worry about  
having an older plugin version that happens to load before a newer  
version, thus forcing all the newer plug-ins to use the older plug-in  
code.



On Nov 15, 2009, at 3:36 AM, Motti Shneor wrote:


Thanks, but the bundleWithIdentifier has its own problems.

1. The identifier is (as far as i know) accessible only from the  
bundle itself, which I don't have! I'm circling around here, without  
access to my own resources!  Must I hard-code the bundle identifier  
as a string constant within each of my plug-ins?


2. Even if I DO follow this rule, how can I manage to distinguish  
between two bundles that include the same plug-in but from different  
versions?


They have the same class, and the same identifier


Really, Isn't there a way for a library (dll, dylib framework etc)  
to know what is its containing bundle?



On 10/11/2009, at 19:42, Douglas Davidson wrote:


On Nov 10, 2009, at 4:59 AM, Motti Shneor wrote:


Thanks guys, but you may have not read all my message ---

The [NSBundle bundleForClass:[self class]];

is unusable for me, because I have many plugins that build from the
same code, and export the same class (of course --- the same class
name).

Obj-C has no name-spaces, and so, If you load 2 such plugins, and
use the [NSBundle bundleForClass:[self class]] in each of them
independently --- you'll get erroneous answers! both of them will
return the same bundle although they come from different bundles.

This is hardly a system "bug" because there are no namespaces, and
for the same class name there is only one bundle.


As others have said, don't do this.  However, to answer your  
question,

the other way to locate your bundle is via bundleWithIdentifier:.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How can a plug-in bundle get access to its own resources?

[Steve Christensen]

I understand your frustration, but as I said, one class instance per  
process is a feature of the Objective-C runtime and has been the case  
since before there was an OS X. Please understand that having 200 plug- 
ins, all using the same class name, is not a typical situation. You  
are doing it to simplify your build process, but that's not a good  
reason for saying that the runtime behavior needs to change.


It looks like your build process is already modifying a number of  
project settings on a per-plugin basis, so adding one more #define  
shouldn't break you. Remember that ALL of the classes in your plugins  
are visible and loaded in the same way, so if any of the others  
besides your plugin's "main" class would have issues being loaded from  
a single plugin, then you'll have to make sure their names are unique  
as well.



On Nov 15, 2009, at 11:35 PM, Motti Shneor wrote:


Thank you all, and thank you Steve - I think the point is clear now.

However, I'm afraid this limit renders the whole Obj-C interface for  
plug-ins impractical for any medium-to-large company with legacy code.


There is nothing more natural than re-implementing an interface  
using the same class. Unfortunately, this is also the common  
practice in C++, Java and other OO languages. Most applications will  
naturally select plugins that fit a specific function by looking for  
"those implementing this specific interface"  usually ---  
implementing the same class! (Yes, I know Java and Obj-C provide  
protocols/Interfaces for that).


Our company makes more than 200 professional-class Audio plug-ins,  
developed along 14 years or so. They all build from one same code  
base, for multi-platform multi-host deployment. It's virtually  
impossible to set a separate class name for every exposed class of  
every plug-in. Not only this is cumbersome, and hard to interface in  
other platforms than Obj-C/Cocoa, it introduces huge pollution to  
the "name space" of both our code, and the host-applications code  
and other makers plug-ins.


In all other code-deployment mechanisms we encountered (Windows  
DLLs. Linux Dynamic libraries. Mac shared-libraries dylibs and even  
C/C++ code bundles, there is always a way for a piece of code when  
run (usually when initialized) to ask where it comes from (i.e. the  
path to the binary file it was loaded from) thus, allowing the code  
access its resources.


If Obj-C intentionally lacks name-spaces, then some other  
replacement mechanism MUST exist to tell one loaded binary from  
another! This,to my opinion directly leads to the Bundle mechanism,  
responsible for loading and unloading of the actual code. It is only  
very natural to ask that code can access its own resources! what's  
simpler than that?


Moreover, Cocoa provides such API (mainBundle) for applications,  
which makes perfect sense to everyone. How is it that ONLY  
application bundles support this API? After all, every code bundle  
is structured the same, and includes resources etc.


I think many plugin code makers, especially those with legacy code,  
and  cross-platform needs, will have to avoid Obj-C APIs in their  
plug-ins. Which is a real pity. The dynamic nature of Obj-C calls  
for such API to exist.


Such an obvious deficiency in the Obj-C and Bundle mechanisms can  
hardly be tolerated in the long run. The situation is error-prone,  
simply because we live in an open-space where other software makers  
could easily introduce a class named just like mine, and confuse the  
system at runtime. There even isn't an error when two same-namesd  
classes are loaded!


The last solution from Steve seems the best way out currently,  
although it's a little hard to introduce into our build system. We  
currently control the product names and the binaries created using  
only the XCode projects facilities --- we use pre-build scripts that  
read the "product definition" from an external database, then modify  
the Project environment accordingly. The Product name is never hard- 
coded, and the high-level interface sources never change to produce  
a new product or a variation of it.


Luckily, #define-s can be introduced at the project level. Maybe  
we'll just do that, If we can limit the number of exposed classes to  
just the plug-in names (over 200 i remind, not including versions  
and variations that must live together).


Any Ideas for the Versioning problem? Does anyone have good  
experience with the Framework version mechanism?


I saw these

myFramework.framework packages with

myFramework.framework
myFramework.framework/Resources (alias)
myFramework.framework/Versions/
myFramework.framework/Versions/A/
myFramework.framework/Versions/Current (alias)

Structures everywhere --- Do they work right? I mean can a host  
application (or host library) load a plug-in by a specific version,  
and KNOW FOR SURE that the right library was loaded?


Any references to how-to implement multi-version code bundles?


O

Re: How can a plug-in bundle get access to its own resources?

[Alastair Houghton]

On Nov 15, 2009, at 11:35 PM, Motti Shneor wrote:

> Thank you all, and thank you Steve - I think the point is clear now.
> 
> However, I'm afraid this limit renders the whole Obj-C interface for plug-ins 
> impractical for any medium-to-large company with legacy code.

Not really, no.

> There is nothing more natural than re-implementing an interface using the 
> same class. Unfortunately, this is also the common practice in C++, Java and 
> other OO languages. Most applications will naturally select plugins that fit 
> a specific function by looking for "those implementing this specific 
> interface"  usually --- implementing the same class! (Yes, I know Java and 
> Obj-C provide protocols/Interfaces for that).

You could conceivably cause yourself trouble in Java doing this as well, 
assuming you are really talking about implementing the exact same class.  In 
practice you probably *aren't* talking about that, because the package name 
will be different, right?

So what's stopping you from building your ObjC class names up in the same way 
that a Java program might use a full class name (e.g. 
com_mycompany_MyPackage_ThisPlugin_Object)?

> In all other code-deployment mechanisms we encountered (Windows DLLs. Linux 
> Dynamic libraries. Mac shared-libraries dylibs and even C/C++ code bundles, 
> there is always a way for a piece of code when run (usually when initialized) 
> to ask where it comes from (i.e. the path to the binary file it was loaded 
> from) thus, allowing the code access its resources.
> 
> If Obj-C intentionally lacks name-spaces, then some other replacement 
> mechanism MUST exist to tell one loaded binary from another! This,to my 
> opinion directly leads to the Bundle mechanism, responsible for loading and 
> unloading of the actual code. It is only very natural to ask that code can 
> access its own resources! what's simpler than that?
> 
> Moreover, Cocoa provides such API (mainBundle) for applications, which makes 
> perfect sense to everyone. How is it that ONLY application bundles support 
> this API? After all, every code bundle is structured the same, and includes 
> resources etc.

It *isn't* only application bundles that support it.  It works just fine with 
*any* bundle.  But the -bundleForClass: method assumes (as does the rest of the 
ObjC runtime) that each ObjC class has a unique name.  The onus is on you to 
conform to that rule; how you do it is your business; one scheme that will work 
is the one I suggested above, copied from Java (though the usual approach is 
just to use a two letter prefix identifying the 
author/company/application/framework and work from there, but as you say, that 
might not work so well for the case you're dealing with).

If you don't like writing these long names out, you could use a #define to 
help, e.g.

 #define P(x)   com_mycompany_MyApp_Plugins_FooPlugin_##x

> The last solution from Steve seems the best way out currently, although it's 
> a little hard to introduce into our build system. We currently control the 
> product names and the binaries created using only the XCode projects 
> facilities --- we use pre-build scripts that read the "product definition" 
> from an external database, then modify the Project environment accordingly. 
> The Product name is never hard-coded, and the high-level interface sources 
> never change to produce a new product or a variation of it.
> 
> Luckily, #define-s can be introduced at the project level. Maybe we'll just 
> do that, If we can limit the number of exposed classes to just the plug-in 
> names (over 200 i remind, not including versions and variations that must 
> live together).

As I say, you must already have unique names for Java, right?

> Any Ideas for the Versioning problem? Does anyone have good experience with 
> the Framework version mechanism?

I'm not 100% certain what you're asking about here, but...

> I saw these
> 
> myFramework.framework packages with
> 
> myFramework.framework
> myFramework.framework/Resources (alias)
> myFramework.framework/Versions/
> myFramework.framework/Versions/A/
> myFramework.framework/Versions/Current (alias)
> 
> Structures everywhere --- Do they work right? I mean can a host application 
> (or host library) load a plug-in by a specific version, and KNOW FOR SURE 
> that the right library was loaded?

They do work, but I suspect they aren't what you're looking for.  The framework 
version stuff is there so that an application or plug-in can link against what 
it considers to be the current version of the framework, and then someone can 
introduce a binary incompatible version without breaking the apps that are 
linking against its predecessor.  It's really only a symlink structure, 
however, just like the similar one used on both Linux and OS X for "ordinary" 
shared objects/dylibs... there isn't anything clever going on per se.

I don't think there's an API for dynamically loading a particular version, 
though; you'll always load the version po

Re: How can a plug-in bundle get access to its own resources?

[Alastair Houghton]

On 17 Nov 2009, at 08:59, Motti Shneor wrote:

> First, to clear things, I'm not WRITING plug-ins. I'm transitioning our 
> EXISTING product line from Carbon to Cocoa, to be able to run within 64bit 
> Host applications (which, do not exist yet.). Within this scope, I 
> contemplate the way to re-package our deployed "plug-in" entities and other 
> frameworks with Obj-C wrappers.

I understand that.  So does everyone else.  We also understand that your code 
base is large and that you don't want to change every existing class name or 
redesign your build system on every platform.  But nothing anyone has said so 
far requires that you do any of those things.  If you think you do, it's 
because you are labouring under some misunderstanding about Cocoa/ObjC.

All we're saying is that *for your ObjC classes*, you need the names to be 
unique across your entire process, and in practice that means prepending them 
with something.  For a plug-in system, especially if it plugs in to code in a 
third-party process, I strongly recommend that you use something akin to Java's 
reverse domain scheme, even though, as I say, that isn't the usual solution for 
Objective-C code.

I don't see why that would require the kind of changes you're indicating it 
would.

> I must be sure that when a plug refers to the base framework, It'll use the 
> exact version it linked agains, and was tested to work with.

Right.  Yes, it will.  The framework versioning mechanism is just a variation 
on the usual symlink system used on most UNIX-like systems for shared 
libraries.  The only difference is that the structure is not flat (so whereas 
you might see e.g. "libcrypto.dylib" symlinked to "libcrypto.0.9.8.dylib", here 
it's the folders that are symlinked).

>> On 16/11/2009, at 18:58, Alastair Houghton wrote:
>> 
>> Moreover, Cocoa provides such API (mainBundle) for applications, which makes 
>> perfect sense to everyone. How is it that ONLY application bundles support 
>> this API? After all, every code bundle is structured the same, and includes 
>> resources etc.
>> 
>> It *isn't* only application bundles that support it.  It works just fine 
>> with *any* bundle.  But the -bundleForClass: method assumes (as does the 
>> rest of the ObjC runtime) that each ObjC class has a unique name.
> 
> I double-checked it, and you're wrong.

Ah, sorry, I see what you meant---you were talking specifically about the 
-mainBundle method itself.  I had misunderstood your sentence (I think perhaps 
a language issue---a native English speaker would probably have used "this" 
rather than "such", which has a somewhat different meaning here).

> When my plug-in bundle is loaded by the host application, and some of my code 
> is being called if it uses the [NSBundle mainBundle]; API it will get the 
> application bundle, not its own bundle. There is no generic API for any 
> running code to ask "what is MY bundle". Only applications can do that.

As you've been told already, you need -bundleForClass:.  The problem you are 
having with it is because you're misusing the Objective-C language and runtime, 
and you're doing that---you claim---because for some reason your Objective-C 
class names can't possibly be prepended with a unique identifier for each 
plug-in.  Quite frankly, I don't buy it; it shouldn't require changes to the 
build system on all your other platforms to achieve that, and it isn't 
complicated.

Kind regards,

Alastair.

--
http://alastairs-place.net



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com