You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/04/21 19:16:29 UTC
[RT] Avalon Bundles and Extensions
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
resources.
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
conventions:
All string values will be kept in a "Resource.properties" 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
bundle.
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
Re: [RT] Avalon Bundles and Extensions
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 23 Apr 2003 22:29, Berin Loritsch wrote:
>
>>Can you help me understand where you are
>>coming from? I am very interested to hear.
>
>
> If there is something unclear in the messages I have written in particular
> differences about DUs and LUs then feel free to ask.
OK. Let me take a closer look so that I can ask an intelligent
question ;P
--
"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
Re: [RT] Avalon Bundles and Extensions
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 23 Apr 2003 22:29, Berin Loritsch wrote:
> Can you help me understand where you are
> coming from? I am very interested to hear.
If there is something unclear in the messages I have written in particular
differences about DUs and LUs then feel free to ask.
--
Cheers,
Peter Donald
"All my life I wanted to be someone; I guess I should have been more
specific."
-- Jane Wagner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles and Extensions
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 23 Apr 2003 22:19, Berin Loritsch wrote:
>
>>>Why are you trying to mingle resources access strategies and packaging
>>>strategies?
>>
>>The Bundle API is in charge of the resource access strategies.
>>The Bundle itself is in charge of holding those resources.
>>
>>In order to have a resource access strategy that is both predictable
>>and extensible, you need to have some knowlege of the packaging itself.
>
>
> Thats not what I have found at all but what do I know.
That's a good question ;P
Seriously, though. What have you found? The links you posted only had
some declaration stuff. I couldn't get a bigger picture of what you
were driving towards. Can you help me understand where you are
coming from? I am very interested to hear.
--
"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
Re: [RT] Avalon Bundles and Extensions
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 23 Apr 2003 22:19, Berin Loritsch wrote:
> > Why are you trying to mingle resources access strategies and packaging
> > strategies?
>
> The Bundle API is in charge of the resource access strategies.
> The Bundle itself is in charge of holding those resources.
>
> In order to have a resource access strategy that is both predictable
> and extensible, you need to have some knowlege of the packaging itself.
Thats not what I have found at all but what do I know.
--
Cheers,
Peter Donald
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles and Extensions
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 23 Apr 2003 19:28, Leo Simons wrote:
> Peter Donald wrote:
> > On Wed, 23 Apr 2003 09:41, Leo Simons wrote:
> >>>>>Basic Avalon Bundle Search Algorithm
> >>>>>------------------------------------
> >>>>>
> >>>>>The basic search algorithm for bundle resources (code, resources,
> >>>>> etc.) should be something like this:
> >
> > Why are you trying to mingle resources access strategies and packaging
> > strategies?
>
> because you need to make sure the typical resource access strategies are
> well-supported by the packaging strategy, it is instrumentative to think
> about them together.
instrumentative?
I think you will find that they are othogonal concepts. Much like the
difference between how to access components differs from typing of
components.
--
Cheers,
Peter Donald
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles and Extensions
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
> On Wed, 23 Apr 2003 09:41, Leo Simons wrote:
>>>>>Basic Avalon Bundle Search Algorithm
>>>>>------------------------------------
>>>>>
>>>>>The basic search algorithm for bundle resources (code, resources, etc.)
>>>>>should be something like this:
>
> Why are you trying to mingle resources access strategies and packaging
> strategies?
because you need to make sure the typical resource access strategies are
well-supported by the packaging strategy, it is instrumentative to think
about them together.
cheers,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles and Extensions
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 23 Apr 2003 09:41, Leo Simons wrote:
>
>>>>>Basic Avalon Bundle Search Algorithm
>>>>>------------------------------------
>>>>>
>>>>>The basic search algorithm for bundle resources (code, resources, etc.)
>>>>>should be something like this:
>
>
> Why are you trying to mingle resources access strategies and packaging
> strategies?
The Bundle API is in charge of the resource access strategies.
The Bundle itself is in charge of holding those resources.
In order to have a resource access strategy that is both predictable
and extensible, you need to have some knowlege of the packaging itself.
--
"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
Re: [RT] Avalon Bundles and Extensions
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 23 Apr 2003 09:41, Leo Simons wrote:
> >>> Basic Avalon Bundle Search Algorithm
> >>> ------------------------------------
> >>>
> >>> The basic search algorithm for bundle resources (code, resources, etc.)
> >>> should be something like this:
Why are you trying to mingle resources access strategies and packaging
strategies?
--
Cheers,
Peter Donald
"The ability to quote is a serviceable substitute for wit." -- Maugham
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles and Extensions
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 22 Apr 2003 22:33, Berin Loritsch wrote:
> RPM is an installer
> mechanism.
packaging system actually that has remarkable similarities to what I have
proposed.
> COM is an object activation framework for C++ based objects.
COM is a component model and it has its own packaging standards.
> Java Extension Mechanism is the use of the META-INF/services,
wrong. META-INF/services has nothing to do with the Java Extension Mechanism.
> 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.
except that Java Extension Mechanism declares dependencies between libraries
and what capable as exporting as a library. services declares the public
resources in the jar...
--
Cheers,
Peter Donald
*------------------------------------------------*
| Those who know how to think need no teachers. |
| - Gandhi |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles and Extensions
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>
> with associated management services. Just like we are trying to solve
> the jar hell, MS had devised several ways for solving the dll hell prior
> to .Net.
>
>> JDBC drivers are nowhere near the mark.
>
>
> I am thinking of the DriverManager setup. JDBC is a well-known example
> of push installation of pluggable functionality. It's IMHO exactly how
> we don't want to do things.
Right--which is why I don't want to consider it.
>
>> ANT tasks are just object
>> inheritance.
>
>
> exactly! Look at the pain we have with custom ant tasks and Gump. We
> need to learn from that.
Right again.
>>>
>>> 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.
>
>
> I think the .sar format has pretty much proven itself. Don't
> underestimate the power of phoenix :D. If not modelled after .sar, I
> think our bundle system should at least offer some kind of compatibility
> with them.
Ok. If you said let's take lessons form SAR, I would have agreeed with
you.
>> Those are examples of where an extension to the basic mechansim would
>> be necessary.
>
>
> yep. My current thinking is we need at most one "base seperator", with
> culture/region being a good one to start from. Everything else should
> probably be "extension". KISS.
Yep--exactly.
>> Which is the reason for the extensions part of the proposal.
>
>
> you haven't gone into who extends what and how yet :D
An application/container would install any and all application
specific "plugins" AKA extensions to the bundle API to augment the
search algorithm.
> +1. We do need to think long and hard about how much we assume as part
> of the general case. Assuming nothing is painful to work with, assuming
> too much means less applicability. Framework dilemma #1 :D
>
> @avalon.dependency assumes nothing atm (the only assumption is that
> something is declared which makes sense to the tools that have to parse
> it). Are you saying you don't want to assume anything at all?
It is the concept of declaration. The Bundle API *should* use that
information. The @avalon.dependency declarations identify a "type"
(e.g. the bundle we need), whether the bundle is "optional" or not,
and a "key" which the bundle probably won't use.
One thing I would like to use is the concept of interface/
implementation. The bundles do not actively refer to one another,
because that is all managed by the bundle API. However, if the
bundle publishes a "role" for itself, we can identify what we need
by that role. The bundle API can verify that a bundle with that
role exists.
For Cocoon, this would address a "Theme" bundle where you can drop in
your look and feel in one bundle.
But I am very open to input on that concept. Let's get a basic
infrastructure first.
>> 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.
>
>
> is a bundle type something with a version? Are versions free-form?
I think we should enforce a version numbering pattern. KISS. The
MAJOR.MINOR.MICRO separation is an accepted standard that most
everyone is familiar with.
>>>> Basic Avalon Bundle Search Algorithm
>>>> ------------------------------------
>>>>
>>>> The basic search algorithm for bundle resources (code, resources, etc.)
>>>> should be something like this:
>>>>
> revised:
>
> 1) always look in the current bundle first
> a) look for local resource
> b) look using extension search pattern in global section
> c) look for global resource
> d) look using extension search pattern in global section
> e) look for default resource
This is exactly opposite of the OSX bundle search scheme. OSX made
their choice for the sake of performance. Are you saying that we
should deviate from that?
> 2) look "up the chain"
> how does that work? Per-container shared repo? Nothing of the kind?
> ie do we implement "shared assemblies"?
> (search order a-e is the same)
The "chain" is the dependency chain. IOW, if my bundle declares that it
needs:
dependency: Theme
dependency: Forum
It would look at the "Theme" bundle (and all its dependencies), and then
the "Forum" bundle (and all its dependencies).
--
"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
Re: [RT] Avalon Bundles and Extensions
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> 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.
I still have to take a better look at OSX bundles.
you will have noted yourself the .Net system is quite extensive, what
with MSIs, the various MMC snapins, the registry format, PKI
integration, ...... We are just taking a first step here :D
>> - 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
- maven
- centipede
>
> All of these have some similarities,
exactly! It's a safe bet the lowest common denominator of all of the
above is the basis of what we want here :D
> and some of them just don't have
> anything to do with the proposal.
disagree: package/bundle/resource management and identification are done
to some extent by all. Build systems, deployment descriptors, package
databases...all share many, many common characteristics.
> For instance: rpm, COM, jdbc drivers,
> and ANT tasks all have nothing to do with this. RPM is an installer
> mechanism.
Among other things, RPM includes a general resource information database
including "common names" for referring to a set of resources, dependency
checking and management, autogeneration of one type of bundle from
another, etc etc.
> COM is an object activation framework for C++ based objects.
with associated management services. Just like we are trying to solve
the jar hell, MS had devised several ways for solving the dll hell prior
to .Net.
> JDBC drivers are nowhere near the mark.
I am thinking of the DriverManager setup. JDBC is a well-known example
of push installation of pluggable functionality. It's IMHO exactly how
we don't want to do things.
> ANT tasks are just object
> inheritance.
exactly! Look at the pain we have with custom ant tasks and Gump. We
need to learn from that.
> I have no clue what "apt" is,
the debian package management system; somewhat similar to RPM in use
case but otherwise very different.
> or PEAR.
think CPAN for PHP.
> 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.
uhm. You might want to look at how netbeans platform integraties with
the java extension mechanism. I dunno what META-INF/services is...
> In the end it is choosing what works.
+1
>>> 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.
I think the .sar format has pretty much proven itself. Don't
underestimate the power of phoenix :D. If not modelled after .sar, I
think our bundle system should at least offer some kind of compatibility
with them.
>>> 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.
yep. My current thinking is we need at most one "base seperator", with
culture/region being a good one to start from. Everything else should
probably be "extension". KISS.
>>> 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.
you haven't gone into who extends what and how yet :D
>>> 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)
>>
>> [many questions]
>
> 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.
+1. We do need to think long and hard about how much we assume as part
of the general case. Assuming nothing is painful to work with, assuming
too much means less applicability. Framework dilemma #1 :D
@avalon.dependency assumes nothing atm (the only assumption is that
something is declared which makes sense to the tools that have to parse
it). Are you saying you don't want to assume anything at all?
>>> 2) Bundle Type identifier
>>
>> what is a "bundle type"?
>
> 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.
is a bundle type something with a version? Are versions free-form?
>> [use i18n as base seperator?]
>
> [it is satisfactory: works for OSX]
>>
>>> Basic Avalon Bundle Search Algorithm
>>> ------------------------------------
>>>
>>> The basic search algorithm for bundle resources (code, resources, etc.)
>>> should be something like this:
>>>
revised:
1) always look in the current bundle first
a) look for local resource
b) look using extension search pattern in global section
c) look for global resource
d) look using extension search pattern in global section
e) look for default resource
2) look "up the chain"
how does that work? Per-container shared repo? Nothing of the kind?
ie do we implement "shared assemblies"?
(search order a-e is the same)
3) For each dependency (in order listed) perform search function (1a-e,2a-e)
>>>
>>> The [Avalon Bundle API will be queried by the container and] 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.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles and Extensions
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: [RT] Avalon Bundles and Extensions
Posted by Leo Simons <le...@apache.org>.
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
- 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
> so it does influence what I wrote here.
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.
> 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.
> 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.
> 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.
> 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)
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?
> 2) Bundle Type identifier
what is a "bundle type"? Similar to a DTD declaration?
> 3) Bundle entry heirarchy:
> /
> <global resources>
> en_US (locale name)/
> <local resources>
>
> In each section (i.e. entry heirarchy), we have the following
> conventions:
>
> All string values will be kept in a "Resource.properties" 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
> bundle.
>
> 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.
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?
> 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.
> 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?
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org