Gerhard Froehlich wrote:
>
> >Gerhard Froehlich wrote:
> >>
> >> Hi Stefano,
> >> can you give a clear separation to Phoenix and Avalon 5?
> >
> >Sorry, I can't really parse the question.
> >
> >What do you mean?
>
> Oh sorry. I was a little bit in a hurry at the weekend.
>
> I follow two main architectural discussions in the moment:
>
> (1) The Avalon 5 Design on the Avalon dev. list
> (2) Cocoon Block Design here
>
> Both approaches want the same:
> "Provide a component oriented framework, where you can easy plugin
> Components
> on runtime".
> I know there are lot of Cocoon and Avalon related details in this two
> concepts,
> but this is IMHO the common denominator.
>
> Peter Donald and Berin Loritsch wrote interesting RTs last days and I see
> lot of parallels to your COB proposal:
> <http://marc.theaimsgroup.com/?l=avalon-dev&m=102513578616579&w=2>
> <http://marc.theaimsgroup.com/?l=avalon-dev&m=102449360809559&w=2>
>
> Therefor I'm little bit concerned that we have double functionality in the
> future,
> especialy when Avalon 5 is coming. I'm concerned that we have a framework
> in a
> framework, which IMAO doesn't make things easier than now:
>
> My worst scenario:
> As a Cocoon 3.0 Developer I must develop my Cocoon components as Avalon 5
> components
> and promote them to the internal Avalon 5 ComponentContainer with the
> special
> Avalon procedure.
> In a second step I have to promote the Cocoon components to the Cocoon
> Kernel or whatever
> with the special Cocoon procedure.
>
> You see what I mean?
>
> But I'm sure that you already made your thoughts about this topic. I just
> want
> to hear your opinion and maybe you can sweep off my concerns in one
> sentence :-).
> What I want is a short comparsion of this two architecures dicussions in
> the moment.
Ah, ok.
I promised Sylvain to come up with a detailed answer to the overlap
between these two efforts and I will, but for new let me give you a
short description of what it is my vision of the concept.
- o -
First of all, Cocoon blocks adopt the exact same design concepts of
Avalon Blocks, in fact, this is why they share the name.
Also, they share the fact that 'hints' are considered harmful: the
container should be in control of module lookup and should not be
'hinted' by the components, or the control is 'reinverted' and SoC is
broken.
Even if many things are shared, there are some differences: mainly, the
block behavior is identified by an interface, which is the service
descriptor.
This could be abstract in Avalon so that the descripting contract could
be either a java interface, a WSDL file or a cocoon sitemap. This is
something we could propose to the Avalon people at the framework level.
The question on the table is:
will it be possible to reuse an avalon container (say Phoenix) to
deploy cocoon blocks?
I honestly have no idea and I'm going to investigate this and ask around
how difficult this could be. This said, I'm all in favor of sharing code
since I'm lazy and I don't want to write it myself :) (these deep
classloading issues are pretty nasty to debug! I've done it once for
JServ and if I can avoid doing it again I'll be happy)
At the same time, those avalon block containers (phonenix, for example)
are not designed to be 'embeddable', but are designed to be called
directly from command line (so they might not be friendly about several
instances running on the same JVM. We'll see (I'll ask avalon-dev about
it).
But there is something to note:
> My worst scenario:
> As a Cocoon 3.0 Developer I must develop my Cocoon components as Avalon 5
> components
> and promote them to the internal Avalon 5 ComponentContainer with the
> special
> Avalon procedure.
> In a second step I have to promote the Cocoon components to the Cocoon
> Kernel or whatever
> with the special Cocoon procedure.
Careful here: first of all, Avalon Blocks were deprecated. They are
talking about 'components'. So, there is a big difference between a
Cocoon Block and an Avalon Component: the first is mostly a sitemap
which exposes a web service, the second is some logic which exposes a
service callable by the program.
So, first of all, it doesn't make any sense to make a 'Cocoon Block'
deployable in, say, James run by Phoenix. It doesn't make sense because
a Cocoon Block uses the sitemap (which is a cocoon-specific concept) as
an interface with the outside of the module.
So, I picture Cocoon being (or containing) two different containers:
- an avalon component container (could be Fortress or Merlin)
- a cocoon block container (could be based on Phoenix or we make our
own)
In that case, the way you write, use and deploy 'avalon components' in
Cocoon and in all other avalon containers is one thing. And this is
totally independent on how your write, use and deploy 'cocoon blocks',
which behave on a completely different level.
At least, this is my vision ATM, but I'm wide open to suggestions,
expecially if they make it easier to implement the concept of cocoon
blocks :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
