Loadable bundles and version control
Loadable bundles and version control
- Subject: Loadable bundles and version control
- From: Steve Israelson <email@hidden>
- Date: Wed, 16 Nov 2005 22:36:46 -0800
So, I have gotten loadable bundles working fine.
Now I have to start thinking how to keep track of their abilities.
Lets say I have a bundle with the ability to play video, called
MoviePlayer.
Now, lets say this will work on older systems etc.
Lets call this MoviePlayer 1.0.
Now, some third party comes along and wants to make a MoviePlayer
bundle that uses OpenGL to play faster or cooler.
Lets call this MoviePlayer 2.0.
Now, a User opens a document that says it makes use of the
MoviePlayer object. The 1.0 version.
So I go and look at all the bundles I can load and see the 1.0 one,
and load it in.
It creates an object of class MovieObject and away I go.
Now, say the user opens another document, and it wants to use the NEW
cool OpenGL MovieObject.
So I go and load that one.
It ALSO wants to make an object of class MovieObject.
What will happen?
You can't have two classes with the same name, that's crazy.
How do I deal with this? What is the best architectural approach?
One idea I have is that the bundle actually loads privately named
classes and those classes have a method that returns the type of
object it is, even though the class name is different.
I would also have to put information in the plist for the bundle so
that I can query it for its capabilities before loading it.
Does anyone have any better ideas on how to do this?
Should I drop down and use the CFPlugIn stuff? Would I gain anything
by doing so?
_______________________________________________
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