Re: Glib resource framework

[Hub Figuière <hfiguiere teaser fr>]

On 22/12/11 03:18 PM, Paul Davis wrote:
> apple gave up the whole "package resources into binary blobs that are
> sort of like files but not really" thing about 10 years ago, after 10
> years of experience with it. i'd like to think we could learn from
> their experience.

The whole "resource" business was designed in the early 80s to deal with
a structured set of data load from a slow mass storage (floppy disk) on
a very constrained memory (128kb). That lead to the resource manager on
Macintosh. It was even used to store the actual executable code. Other
times, other constrains.
But it was fragile (you could easily corrupt it) and sometime would
cause crashes.
The "package bundle" we see on MacOS now is inherited from NeXT and
Apple started using it in MacOS 10.0 in 2001 instead of "resources".

The only major difference between a package bundle and things installed
in a prefix is that the package bundle is all self contained. It does
not prevent from using a package manager but it make it less a necessity[1]

Also, unlike the proposed "binary resource" this would work with
applications written in Python, Ruby, etc. where all the files could be
located in that self contained package bundle. Like, say, the
gnome-shell. This is already done at large on MacOS.

Supporting this concept would involve the following changes:

-API in gio to access bundle and content so that application developer
can write relocatable software. They can be designed to work either way.

-change in the autoconf macros to allow dealing with package bundles easily.

-change in Nautilus to deal with package bundle, and possibly the shell
and other core components that needs to know about it

-fix gsettings[2]

-performs some changes to ldd to support linkage relative to the
executable. I'm sure we can work around it with a shell-script wrapper;
wrapper that might also be needed to support other OS, but I do believe
it would be beneficial to investigate that possibility.

Ideally there would be a spec written so that it becomes cross-desktop
so that KDE Software Collection could benefit from it the same way.


Hub

[1] I'm no advocating to drop package management here.
[2] This is left as an exercise to the reader to guess what needs
fixing. I have some ideas, but tl;dr