Resource framework, relocatability (was Re: Glib: a Win32 discussion)

[Alexander Larsson <alexl redhat com>]

On Wed, 2011-04-06 at 23:34 +0200, Kean Johnston wrote:

> Last, but by no means least, is the reliance on "compiled" files, like 
> compiled schemas (or in the case of Gtk, icon caches). On UNIX systems 
> where things are installed in a universally-accessible location, this isn't 
> a problem, but on Win32, where multiple applications could all include 
> their own private copies of the DLL's, this is a problem. Fixing this is a 
> bit tricky but very doable. Windows does provide two places that are 
> predictable and universally accessible: the registry, and %ProgramData%. 
> The registry is a poor choice except perhaps for location files inside 
> %ProgramData%. The registry is slow, and also imposes some severe 
> limitations on key sizes etc. This can be very easily addressed by 
> compiling Glib with LIBDIR set to something like "%ProgramData%\Glib\2.x" 
> and ensuring that functions like g_file_get_contents() or g_open() all call 
> ExpandEnvironmentStrings() on Win32. This is also a relatively small change 
> and doesn't change any existing API's (although on Win32 it will have a 
> behaviour change).

Things like this is a problem on unix too, as it makes relocatable
apps/libs hard. 

I've long had this dream of perfectly relocatable gnome libraries/apps
where the executable file itself contained all the information it needs.
Relocating something like that is trivial (LD_LIBRARY_PATH is all that
is needed).

The plan I have is to add a resource system to gio, similar to
http://doc.qt.nokia.com/4.0/resources.html where you describe the
resources in a file, and during the build this gets compiled and linked
into a read-only section in the library/executable. Then we'd have an
API that allows easy lookup of named resources (in a combined namespace
for all libraries in the app) such that you can easily get inputstreams
to the data or direct pointers to the data.

This allows all kinds of nice extras, like transparent compressed
resources (although these will not allow direct pointers) and
locale-specific versions of resource files. It will also ensure that all
users on the system map the same resource data instead of loading it in
each process.

Another aspect is translations. I've been thinking a bit about ways to
relocate these. We could internalize a copy of gettext into glib and
modify it to be able to read mo files directly from the binary. Of
course, this would make the library kind of large, but not larger than
the current total package size. It would be harder to strip out unused
translations in an installation though, but I have some ideas that can
solve this.

Introspection data could also be made part of the shared library itself,
rather than a separate file. It would just be a custom elf section.

Of course, some files are inherently made to be external, read by other
applications. Such files are hard to relocate, like application icons,
desktop files, icon themes, widget themes, plugins, custom mimetype
descriptions, dbus service files. I don't really know what to do with
these.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a short-sighted amnesiac cop with a secret. She's a cynical kleptomaniac 
lawyer in the witness protection program. They fight crime!