Besides code a qooxdoo application maintains a fair amount of data that represents some sort of resources. This might be negligible for small to medium size applications, but becomes significant for large apps. The resources fall roughly into two categories,

1. Internationalization (I18N) Data
   like translated strings and locale information (such as currency, date and time formats, asf.)
2. File Resources
   mostly images like PNG and GIF graphics, but also static HTML and CSS files, sound and multimedia files, asf.

Many of these resources need an internal representation in the qooxdoo app. E.g. translated strings are stored as key:value pairs of maps, and images are stored with their size and location. All this data requires space that shows up in  sizes of application files, as they are transfered from server to browser.

Since version 0.8 qooxdoo stored nearly all of this information in the very first package of an application, the package containing the loader code which would bootstrap the application. For large applications, which lots of graphics and translated strings, this initial package would become very large. It would also defy the idea and benefits gained with application parts, as the data would cover all parts of the application, whether they were loaded during run time or not.

So we thought about splitting all these resource data out from the loader package and into the packages that actually need them. So the plan is to have translated strings in the package that actually uses them, register image data with them, and so forth. In a first step we now have forked out the static resources (category 2. above), so they would be filed with the requiring package and loaded together with it. This can decrease the size of the loader package dramatically, hence increase transfer speed and startup time of the application, and avoids loading of unnecessary data.

To increase the impact of this measure even more, the merging of packages within parts could use some enhancement too. Hence, a new experimental configuration feature was added to the generator. If you add no-merge-private-package : true to a part's config definition, the one package that is specific to this part (it's always exactly one) will be retained and will not merge however small it might be. This allows you to retain these specific packages, together with all the resources they might require.

This is particular interesting if you define parts that draw a lot of resources, but are rarely used or, even better, where you know only one of several parts will be loaded during run time (alternative parts). A concrete example for this scenario is an application that comes with multiple themes, only one of which will be loaded at run time. Each theme can maintain a large collection of resources besides the theme classes. Having those in separate parts will allow you to load just one of them with all its resource info at run time, without the others blowing up the sum total of loaded packages.

We'll see how this stream of thought will continue. For example, currently it is orthogonal to the splitting out of I18N data in locale-specific files, but I have the feeling that these concepts will nicely converge.