Re: FHS compliance/Abstraction of NSBundle

[Richard Frith-Macdonald]

On 9 May 2006, at 03:21, Gregory John Casamento wrote:
> NSBundle Abstraction
> ====================
> Why should we be constrained to the .app wrapper?
>
> One of the things which I've done on the NibCompatibility branch is  
> to abstract the model loading mechanism so that it has "loader"  
> classes.  Each loader handles a specific type of gui model (i.e.  
> GSGormLoader for gorms, GSNibLoader for nibs and GSGModelLoader for  
> gmodels).  Each loader registers itself with a factory class so  
> that the scheme is entirely open and can be easily extended.  A  
> similar scheme would be possible to implement for NSBundles.
>
> This would effectively decouple GNUstep from it's bundle structure  
> and allow the use of any given bundle structure.   This would  
> allow, for instance, people to distribute apps as ".app" wrappers,  
> or in other formats since how the bundle would find its resources  
> would be abstracted into the bundle loading mechanism for each  
> different type GNUstep could support.
>
> Please let me know what you think.

I don't think it's a bad idea ... but it's probably one which is  
'waiting for an application'.

I remember discussing this about a year ago, with reference to  
monolithic distribution of an app on windows ... the idea was to put  
all resources inside a single zip image linked in to the executable,  
so that you could access the resources via NSBundle as normal, but  
everything would actually be in a single executable which could be  
copied and moved around very simply.  The NSBundle would uncompress  
data files into a temporary directory on demand.   Anyway, that's one  
possible application.

However ... as decoupling from the underlying bundle structure is  
precisely what NSBundle does anyway, there does not seem to be a need  
for extra generic code to support it.  You access things via NSBundle  
rather than doing them directly, so subclassing NSBundle lets you use  
any representation you like for the data stored in the bundle.  If  
people needed alternative storage formats they could easily support  
them that way, so I guess nobody has really needed them (after all,  
the default format is really simple).

So ... if we have a concrete application that's reasonable important  
to devote time to, it would be good to code an NSBundle subclass to  
handle that application and add makefile extensions to package up  
resources in the manner the new bundle expects.  Handling a  
compressed archive seems the obvious first choice.