Re: Proposal: NSBundle frameworkWithName:

[David Ayers]

Stefan Urbanek wrote:

> There are two points about this proposal: to be able to load framework 
> dynamically and to create an interface without having filesystem 
> involved. First think allows you to not to create dependencies for an 
> application, that means that the presence of a framework is not 
> required on the system where application is being run. Second is a 
> simplification of the bundle interface and is a small step towards 
> integrated environment. GNUstep already knows where frameworks are, I 
> just need to specify a name.
>
> Framework is a bundle and more. It should contain development 
> interface and more versions. For the application, it is just a bundle, 
> for developer it is more.
>
> Concrete example is scripting support with StepTalk. Scripting is 
> optional. Proposed functionality will remove need of writing bundle 
> searching code from all applications and servers that use scripting 
> optionally. Like application scripting support now is bundled in a 
> bundle which is loaded when requested. I would like to extend that 
> bundle with programming interface so developers can have more controll 
> when using it, therefore it should be turned into a framework. So to 
> look for a scripting support will be sufficient to check for [NSBundle 
> frameworkWithName:@"AppScripting"] instead of traversing all possible 
> rameworks directories.
>
> Another example is optionally scriptable servers where one can add 
> optional scriptability to the object environment of the server. It is 
> analogous to SQL queries (StepTalk scripts) on database servers 
> (GNUstep DO servers).
>
> The proposal is also about reusability of code. I think that this kind 
> of code can be reused in many other applications/tools. And because 
> there are already some private methods with similar functionality, I 
> think that they can be made public, slightly modified and made ready 
> to be reused.
>
> What do you think?

Hi Stefan,

I understand you're trying to push GNUstep into a new visionary era with 
the "integrated environment" concept of yours.  It seems very intriging, 
but I'm not sure the approach is correct.  Frameworks, as defined be the 
current FSF GCC semantics and framworks as defines be Apple's tool chain 
semantics are already very different.  I think we should focus in 
merging these semantics, rather than extending the FSF GCC version.

If I understand you correctly it's a loadable bundle which exports 
headers.  User code should be able to import the headers and compile 
with them, without having to link against it.  Maybe you should 
introduce a new name for it, as this is different from what FSF GCC and 
Apple's tool chain thinks what frameworks are.

A good start would be defining exactly how you think your 
"DynamicFramework" should work in light of preprocessors finding 
headers, linking symbol resolution and dynamic loading.  My first guess 
is "everything like Frameworks as Apple defines them but don't bail out 
when the framework is missing at runtime and symbols references can't be 
resolved"... I guess you'll have to do a lot of GCC and ld tweaking for 
that.  The second guess is, as loadable bundles but export headers.  
This might be a more viable aproach eventhough the things you are 
allowed to put in the exported headers are probably very limited.  My 
guess would be protocols and catagories on classes known to all client 
apps and no classes specific to the "DynamicFramework". But does that 
really justify a new bundle type?

I guess a developer can't compile a code using a "DynamicFramework" 
without it being installed, but your approach seems to allow running 
it.  It also means, eventhough I may never use StepTalk within ... lets 
take PC for example, I won't be able to compile PC if it #included the 
StepTalk headers unless I also install StepTalk.

To do what you want now, all you really need is a stable protocol 
header, that each "client" app would copy into thier source tree and use 
conventional loadable bundles (aren't you doing that currently?).  This 
isn't really elegant but it serves the purpose without introducing the 
complexity of yet another bundle type and it's implications for the GCC 
tool chains.

Cheers,
David