avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] Avalon Bundles and Extensions
Date Tue, 22 Apr 2003 12:33:10 GMT
Leo Simons wrote:
> Berin Loritsch wrote:
> 
>> So far, the best document I have seen on what my needs are is the
>> MacOS X Bundle specification,
> 
> 
> existing things to look at (random order, top of head):
> 
> - .Net assemblies
> - OSX bundles

My proposal is actually modeled after these.

> - OSGi bundles
> - jEdit plugins
> - eclipse plugins
> - netbeans plugins
> - maven plugins
> - ant tasks
> - COM; activex objects
> - jdbc drivers
> - rpm
> - apt
> - CPAN
> - PEAR
> - .war
> - .ear
> - .sar
> - .eob
> - Java Extension Mechanism

All of these have some similarities, and some of them just don't have
anything to do with the proposal.  For instance: rpm, COM, jdbc drivers,
and ANT tasks all have nothing to do with this.  RPM is an installer
mechanism.  COM is an object activation framework for C++ based objects.
JDBC drivers are nowhere near the mark.  ANT tasks are just object
inheritance.

I have no clue what "apt" is, or PEAR.

Java Extension Mechanism is the use of the META-INF/services, or adding
entries in the manifest file.  Both of these are ways of recording meta
information, so they are not fully what we are looking at.

That leaves the packaging standards:

.war
.ear
.sar
.eob
OSGI bundles
.Net assemblies (need more info)
OSX bundles
and the plugins.

All of these do have some similar points, however there are some
differences as well.

Each has a place to put the meta-info, or descriptor information.
Each has a place for code and resources--though few are structured.

As to placing code and resources, that is where the bulk of them
differ.  Some put all code in a special lib/ or classes/ directory
(I don't like this).  Others put the resources in a special place.

In the end it is choosing what works.


> apple has historically done a nice job of packaging up apps. Apps which 
> are built for the mac often run well on PC as well. Photoshop is a nice 
> example. You can move the entire installation elsewhere (drag-and-drop), 
> and it will simply reconfigure itself correctly on startup.
> 
> With .Net, things are about as clean. I really like assemblies so far.
> 
> Everything else I know mostly pales in comparison to these two.

Which is why I am trying to model after that.


>> 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.
> 
> 
> others are more generic: java services, java daemons, java server 
> applications. (the basic phoenix usecases). Take JAMES as a concrete 
> example.

I believe you are confusing the picture.  Lets model after something
proven, and fine tune for our needs.

>> 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.
> 
> Resources may be unique to a deployment setup, operating system, 
> availability of externally hosted services.

Those are examples of where an extension to the basic mechansim would
be necessary.

>> 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
>> resources.
>>
>> I think the same general approach should be taken.
> 
> I think the algorithm needs to be customizable and overridable for a 
> particular deployment by the application deployer / administrator on a 
> granular level, as is possible and cleanly implemented in .Net.

Which is the reason for the extensions part of the proposal.

>> 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)
> 
> 
> what are the minimum requirements which are not declared (ie which are 
> not a service of some kind)? A working directory, for example? Or is the 
> idea to declare everything, have a container automatically provide some 
> of the deps? How much do we want to ass-u-me? Do you want to be able to 
> package any kind of software inside an assembly?

It is similar in spirit to the @avalon.dependency meta tag.  The
container can then take care of downloading the dependency or simply
verifying its existence at load time.

As much as possible, I would like to leverage concepts we already
use.


>> 2) Bundle Type identifier
> 
> 
> what is a "bundle type"? Similar to a DTD declaration?

No, it is declaring whether the bundle is an Avalon bundle, a GUIApp
bundle (an extension of Avalon), a Cocoon bundle, etc.

That way the bundle API would be able to determine if the extension
to handle that type of bundle exists in the application.  If not,
the container would be able to fail early.

> 
>> 3) Bundle entry heirarchy:
>>     /
>>      <global resources>
>>      en_US (locale name)/
>>        <local resources>
>>
>> We will in effect be extending the ResourceBundle API somewhat as
>> there is some overlap.
> 
> 
> does it always make sense to use 18n as a base seperator in a resource 
> hierarchy? Do we want to be able to customize and declare the hierarchy 
> (ie LDAP-style)? How much flexibility / structure do we want?

I believe it is a satisfactory separator.  Again, I am taking this from
OSX bundles which work quite nicely.

> 
>> 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
> 
> 
> a basic rule in i10n is to look for the localized resource corresponding 
> to the system you're running on and use that, and if that is unavailable 
> follow the preference scheme set up for the system, and only if no 
> preference scheme is available default to some preconfigured default 
> (which is usually <default>, en-us, en-uk, sp, fr, ... or something like 
> that.

L10n, but anyway...

Right.  That is what we should do (and is specified by OSX bundles)


>> 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.
> 
> 
> are you talking about "bundle API" as something active, IOW something 
> which components inside a bundle query themselves, or as something which 
> is behind the scenes, ie the components just ServiceManager.lookup() 
> things?

It is an API that the *CONTAINER* uses to manage resource bundles.  A
bundle is passive, but the bundle API is active.  In effect, it is part
of the container.


-- 
"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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message