Peter Donald wrote:
>
> Maybe what would be to refactor the *Info into something useful to both
> Phoenix/Cocoon.
The big thing is that it would have to be part of Avalon--there is no sense
in including a server with a servlet.
> The only issue then is that Cocoon woul dhave to include the extra
> attribute "version" for each service. I don't think this is too much overhead.
This is not a problem.
> >On Monday 19 March 2001 20:37, Berin Loritsch wrote:
> >> I will try to see where it would fit in the Avalon Framework. It would be
> >> perfect for replacing the DefaultComponentManager implementation in
> >> Avalon--but the Handler and Factory implementations may need a
> >> subpackage.
> >
> >The C2 class mentioned by Berin (ComponentFactory) implements ObjectFactory,
> >not (phoenix) Factory. This class doesn't really deal with pooling, though.
> >
> >Is there some degree of redundancy between Factory and ObjectFactory?
I am not sure. I altered ObjectFactory to be an ObjectFactory (it creates
Objects, not Poolables). That way it can be used in Factory contexts and
in Pooling contexts. That is how I have one class that handles the
commissioning and decommissioning of Components. It really reduces the
amount of redundant code, and makes the system more stable.
> Yep - the difference mainly was that ObjectFactory deals with only one type
> while Factory deals with multitude of types. As Avalon progresses I suspect
> we will see a homogenisation of these cases.
>
> >At this point we want to be sure we're making the right decision as to what
> >to base our blocks upon.
>
> You mean blocks as in Phoenix Blocks or just components in general.
The framework I created is for Components. It works quite well in that scope.
I would be sad to see it deal exclusively with Blocks.
> >At first sight it appeared to us that just
> >generalizing C2's component management classes and proposing moving them to
> >the Avalon top-level package would be the right thing to do (tm), but your
> >comment appears to suggest that Camelot would be the right place to move
> these
> >components. What do you think?
>
> Not really sure - what do you think of the above approach. If that was
> adopted we could make a new package that dealt with management and
> delegation of roles/services. Dependency trees between components (I assume
> that doesn't exist in Cocoon???) could also be dealt with by build a DAG etc.
Here is my input: I refactered Cocoon so that Cocoon can have a good foundation
for ComponentManagement and Selection. If we move that framework into Avalon,
it benefits a wider population. If we move it to Camelot or Pheonix, then we
again narrow our focus and the classes are of no use to Cocoon--why move them?
They _need_ to be in Avalon, and then specializations can be made in Camelot
or Pheonix. I propose moving the Component framework to Avalon, with a really
simple Role tool, and then we can create specializations that would really
benefit Camelot or Pheonix.
Anything else would not only be a loss of focus, but wouldn't benefit the
largest group of people.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
