avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <jpra...@yahoo.de>
Subject LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block Support]
Date Sat, 26 Apr 2003 09:23:52 GMT
hi Peter,
hi all,

for everyone joining the discussion: 
[LU .. Library Unit]
[DU .. Deployable Unit]

I distilled our ongoing discussion (which I find very constructive and
interesting) about DUs and LUs in a new message to decrement the entropy
level. [;-)]

Regarding Bundles (Berin)

I have followed the thread on Bundles with great interest, an am very
glad that you brought up the discussion. I have looked at CFBundle and
CFPlugin (which is a lightweight COM spec on top of CFBUndle). In
Peter's terms CFBundle would be described as DU. [please correct me if I
am wrong in your opion]  - It can contain executable code, library code,
configuration and resources (localizables and global resources). I think
we could look at some of the structures (plist especially). I must
confess I have never used the CFBundle API, but would like to by a
Titanium, if I had enough money. 

API Design [Active vs Passive]

If I got that right, you mean that the class represenatatives of LUs and
DUs should only contain the meta information (merely data), not
algorithms how to do something with them, except very simple things.
This is something you do with XxxService or XxxManager clases - right?

Questions and Design discussion:

* Library DUs

LUs are loaded by DUs - period.
Not all DUs provide all the LUs. (which mean contains).
Should there be a distinction between DUs that are mainly library DUs
(kind of plugins) and DUs that are apps.

the provides and depends would be implemented with the Java Optional
Package Manifest entries.

LU: trax-Transformer-XYZ.lu { povides: trax-Transformer/1.0 }

trax-Using-App1.lu { provides: x.y.z/0.3;   dependencies:
trax-Transformer/1.0 }
trax-Using-App1.du { libraries: { trax-Using-App1.lu} , conf: { } }
trax-Using-App2.lu { provides: foo-bar/0.5; dependencies:
trax-Transformer/1.0 }
trax-Using-App2.du { libraries: { trax-Using-App2.lu }, conf: { } }

If we don't support library DUs - should the model be that the first DU
that contains a needed LU will be used to import/link to that LU?
if yes, this probably means that for a DU to be sure it *must* contain
all the linked/dependency LUs.

Perhaps we could solve this by using an apt-get like mechanism for
fetching certain LUs, when not available locally from somewhere. [when
the user deploys the DU and a LU dependency ]. Are those then DUs? And
if yes Library DUs?

* Dependant DUs
I think it would make sense to be able to state that for instance the DU
a.du depends on b.du to there. (dependency not only on a lu level)

* Exportable/Unexportable LUs
I think the DU should be able to declare whether certain contained LUs
should be exportable. If a DU declares a LU to be exportable, other DUs
can link to it. (code sharing)

* Dependecy information

Where should the LU dependency (which means depending on certain LUs) go
Does it make sense to put it in the DU meta descriptor?
If DUs itself contain code (which is probably a hack anyway) yes,
otherwise the LU dependency information should go into the LU.
The DU can recursively question all its containing LUs which
dependencies they have and so compile a list of depending LU for the
whole DU.

* DU usagae scenarios

The question: Who uses as DU, and how?
In my opinion: Depends on the environment. [As you said]

- ECM Style container environment:
Most of the time use will stay within the DU itself. The only thing that
occurs that some LUs are not contained but external used. Or on the
other hand if the DU itself provides LUs to other DUs. (bidirectional)

Here some kind of micro kernel would make sense.
DU unloading/loading listeners would also make sense, which other DUs
can subscribe to. [as you already said]

- Cocoon/Webapp Style container environment:
The Core framework, for instance Sitemap Processor, will use the DUs to
satisfy requests.
If every usage would be bounded to a request/response cycle, everything
would be find, but: Session state! - Some classes of a DU/LU might get
stored in a session state.

* Configuration and Meta Data

How should we define profiles/meta data?

Configuration: XML Schema/Profile Template language.
[Implementation Note] This could get distilled from the @doclet tags.

What I would very much like here is also some kind of security
information, for instance what permissions are used and which are needed
in order for the DU to run. [this information must be provided by LU
developer?, packaged with the LU metadata.]
In current environments (especially WAR) configuring the security.policy
is a pain since you don't know in adavnce what security dependencies
exist [I often end up giving a java.security.AllPermission.] This would
be a major relieve for the deployer/sysadmin.

-- Jakob

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

View raw message