Re: Requirements for implementing Cocoon Blocks

Ulrich Mayring wrote:
> Leo Simons wrote:
> 
>> Ulrich Mayring wrote:
>>
>> Probably. But the idea is to do a proper extraction of that container 
>> framework and do as much work as possible within the avalon scope. 
>> Peeps are talking of building "profiles" on top of such a framework to 
>> handle more specific needs, with easy tweaking of those profiles for 
>> your application-specific needs. SoC, really.
> 
> 
> If it's possible I'm all for it. So far Cocoon is a major customer, 
> maybe there are some others, I don't know.

@apache, there's cocoon, james, and turbine3 (in development). Other 
Open source projects using avalon include OpenORB and EOB, and more and 
more are becoming 'compatible'.

Outside apache, there's a few fortune-500 (ain't that what they call it) 
businesses, as well as some of europe's biggest ICT players.

> What do you mean by arbitrary partitioning? There already is arbitrary 
> partitioning by way of Avalon components. How much more arbitrary do you 
> want to become? For example, do you want to do something like this:
> 
> arbitrary_code --> Java class
> Java classes --> component
> components --> block
> blocks --> application
> 
> Where you have four different ways of partitioning? That would seem not 
> very arbitrary - the developer has to adhere to four different contracts 
> and what if he needs a fifth partition?
> 
> Arbitrary partitioning to me would mean something like this:
> 
> arbitrary_code --> component
> components --> component
> 
> While this is more elegant, because it has only one contract and the 
> developer can be real arbitrary, it does not seem very useful to me.

that's the idea. Only arbitrary_code must adhere to the avalon lifecycle 
and contracts (ie it must be passive), and maybe in the future also 
expose some mnimal meta info, though the exposure mechanism may vary.

consider:

----------------------
| ------------------ |
| | ---  ---  ---  | |
| | |A|  | |  | |  | |
| | ---  ---  ---  | |
| |                | |
| | ---            | |
| | | | partition1 | |
| | ---            | |
| ------------------ |
|                    |
| ------------------ |
| | ---  ---  ---  | |
| | | |  | |  | |  | |
| | ---  ---  ---  | |
| |                | |
| | ---            | |
| | |C| partition2 | |
| | ---            | |
| ------------------ |
| partition3         |
----------------------
      Machine 1

----------------------
| ------------------ |
| | ---  ---  ---  | |
| | |D|  | |  | |  | |
| | ---  ---  ---  | |
| |                | |
| | ---            | |
| | | | partition5 | |
| | ---            | |
| ------------------ |
|                    |
| ------------------ |
| | ---  ---  ---  | |
| | | |  | |  | |  | |
| | ---  ---  ---  | |
| |                | |
| | ---            | |
| | |E| partition6 | |
| | ---            | |
| ------------------ |
| partition4         |
----------------------
      Machine 2

Now E needs a service that is only provided by C. What I want is 
something like

/** @attribute AvalonDependency( C.ROLE, optional="false" ) */
interface E
{
	public static String ROLE = "E";
}

// somewhere inside EImpl
sm.lookup( C.ROLE );

to actually work, regardless of whether the runtime setup is as complex 
as above or simply

-----------
| --- --- |
| |E| |C| |
| --- --- |
-----------

greetz!

- Leo

PS: testing....does this come through twice....testing....