At 11:32 19/3/01 +0100, Ricardo Rocha wrote:
>> >Thinking bigger, "RoleInfo" actually embodies the notion of "Avalon-based
>> >framework", a concept that might well deserve first-class citizen status
>> > in the Avalon set of abstractions.
>>
>> In Avalon we have ServiceInfo == RoleInfo
>
>It appears to me that BlockInfo comes closer to what we're discussing here,
>namely info about the _role protocol_ for a given framework.
err ... scratches head - yep your right ... ;)
>Q: can we safely asume that the "role protocol" made available by RoleUtils
>and RoleInfo has the same semantics as the role dependency list provided by
>BlockInfo? We're talking about the roles _defined_ by the framework/block,
>rather than (external) roles it might depend on...
Almost RoleInfo also defines another dimension (namely the default classes
that implement the role).
>At Bibop, we've used C2's component management classes, slightly modified to
>decouple them from C2 and make them usable by any framework providing info on
>its role protocol, hence the "RoleInfo" interface.
>
>If BlockInfo already provides the same semantics and functionality, the
>proposed RoleInfo interface might indeed be redundant...
Maybe what would be to refactor the *Info into something useful to both
Phoenix/Cocoon.
Having a look at BlockInfo again there are large similarities between the
interfaces. What RoleInfo calls "shorthand" BlockInfo/DependencyInfo calls
"role". What RoleInfo calls "name" BlockInfo/DependencyInfo calls "service".
The other differences are Phoenixs ServiceInfo also embeds a version string
and some extra information in BlockInfo (namely services it offers and
meta-info like author). RoleInfo also specifies a default implementation
which BlockInfo doesn't.
Having a look at it we could homogenize the names and do something like
(using Phoenixes current naming system).
RoleInfo
{
getDependency( role );
getDependencies()
}
CocoonInfo extends RoleInfo
{
String getDefaultImplementation( role );
}
BlockInfo extends RoleInfo
{
getServices();
getMetaInfo();
}
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.
>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?
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.
>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.
Thoughts?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
