cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [RT] Avalon Bundles and Extensions
Date Mon, 21 Apr 2003 17:16:29 GMT
It is true that there is no one-size-fits-all bundle mechanism that will
fit 100% of all the users all the time.  However, if we architect things
the right way, we can provide a way to extend the bundle concept in
application specific ways.

So far, the best document I have seen on what my needs are is the
MacOS X Bundle specification, so it does influence what I wrote here.

Let's look at a couple examples that are just different enough to show
that things need to be changed a little--although the general way of
doing things is the same.  Our Use Cases are GUIApp bundles and Cocoon
bundles, each of which extend the Avalon bundle.  GUIApp may need to get
certain resources that are unique to a specific look and feel, locale,
or combination of locale and look and feel.  Cocoon will need to get
certain resources that are unique to a theme, locale, or combination.

The actual resource types are a bit different, and the actual search
logic will be a bit different as well.  The general search logic would
be identified in the Avalon Bundle API.  Each bundle would be marked
with the type of extensions it needs.

With MacOS X bundles, the search algorithm looks for global resources/
code/etc. first.  If it can't find that resource, it looks for localized

I think the same general approach should be taken.  However, in the
case of GUIApp/Cocoon bundles the Avalon Bundle API would allow the
application to initialize it with a set of BundleExtensions so that
we can augment the search logic for the resource.

The GUIApp/COcoon bundle extension would augment the search logic to
attempt to look for regular resources first, and then for a theme/LaF
specific resource next.

This allows the respective applications to provide the types of bundles
it will support, so that the Avalon Bundle API can detect wether the
bundle is supported at load time, and throw an error or ignore the
bundle (whatever the choice is).

Basic Avalon Bundle Spec

We need the following information to make this work the best way:

1) List of requirements (other bundles/libraries w/versions)
2) Bundle Type identifier
3) Bundle entry heirarchy:
      <global resources>
      en_US (locale name)/
        <local resources>

In each section (i.e. entry heirarchy), we have the following

All string values will be kept in a "" file.
We can use URIs like "string:ok" to make the search a bit more
efficient.  All images will be found by their file name in the

Extensions might include support for XML based string resources, but
that would not be by default.

We will in effect be extending the ResourceBundle API somewhat as
there is some overlap.

Basic Avalon Bundle Search Algorithm

The basic search algorithm for bundle resources (code, resources, etc.)
should be something like this:

1) Always look in the current bundle first.
    a) look for global resource
    b) look using extension search pattern in global section
    c) look for local resource
    d) look using extension search pattern in local section
2) For each dependency (in order listed) perform search function (1a-d)

The Avalon Bundle API will return the first match it finds, and cache
it in a SoftReference so that it will be quicker to find it again later,
but we won't keep too much in memory at one time.

Basic Avalon API Needs

We need the ability to create bundles programatically
(IDE/ANT integration), as well as to perform lookups.

"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock

View raw message