On Tue, 28 May 2002 15:57, Adam Murdoch wrote:
> > yep - Thats why I said it was UGLY ;) It still works (as the
> > MSServiceManager gets wrapped in DSM later) but I am in middle of
> > reorganizing that stuff.
>
> So why does the property store need to be a service?
Why not? ;)
I thought it would be good to make it a service as then everything is
homogenized.
> > > What did you have in mind?
> >
> > Basically I was thinking that you should be able to pass
> > * some metainfo object (ie info about type)
> > * some metadata object (ie instance about instance)
>
> What are some examples of the kind of info we'd need?
Mainly the roles that the component implements and the roles that the
component requires. We could add cutesy stuff in there aswell (like
versioning etc) but that is secondary to the other bits IMO.
>
> > The ServiceRegistry interface is just the "writing" counterpart to
> > ServiceManager (like TypeRegistry/TypeManager etc).
>
> Ok. Would this be a scoped service?
Not sure - probably it would be just an interface into ServiceKernel which
would be scoped .. maybe (not sure yet - need to play).
> One thing we need (and I'm not sure
> if ServiceRegistry is a good candidate) is some way to mess with the
> services contained in an execution frame - eg when creating a child
> execution frame, we need some way of adding new services, overriding
> others, and hiding others.
agreed.
> Another thing that would be nice (this is more of a ServiceKernel thing) is
> to provide a hook so that a service can hand off the management of nested
> services to the kernel.
Sounds good. So each service is capable of being a container and if they
follow some rules they can reuse infrastructure. This is actually the way
Bluestones/HPs CSF (Core Services Framework) works (except they have a supped
up server orientated version).
> We have a few aggregate services, eg the vfs, with
> nested providers, or the deployer, with nested type deployers. The
> extension manager should probably be an aggregate service, too. Currently,
> each aggregate service has to manage the whole locate, instantiate,
> configure, initialise, cleanup lifecycle thing. All they really need is
> something they hand a {role, type-name} to, and receive back a ready-to-use
> instance, that is private to the service and gets cleaned up when the
> service does.
>
> Anything we can reuse from avalon to do this?
Probably - it will require a little bit of code wrangling but it should be
possible.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
