On Fri, 31 May 2002 17:59, Stephen McConnell wrote: > Looking at a real example - the assembly of an ORB - the information > supplied to an ORB to assemble itself is specific to an ORB component. > As shown in the above example, its a bunch of interceptor declarations.
The problem is that there is no way that I can think of of passing in configuration without restricting yourself to a particular implementation. For instance most roles/interfaces can have multiple implementations. One implementation may require configuration, one may not require configuration (it may be fixed at compile time), one configuration schema may be different from another. One implementation may have similar contained components but represented completely and utterly differently or whatever. ie Are interceptors specific to OpenORB implementation? or are they generic across all Corba ORBs? We came across similar problems with hierarchial configuration. ie Where configuration for component A is inside component B's configuration. We can't really determine that component B even has a sub-component A unless we instantiate B and let B interpret its own configuration. (Or unless we standardize the format of all configuration schemas which does not seem feasible). Our conclusion wrt to Configuration was that we should not have hierarchial configuration at all or that we should validate it at runtime (effectively each container component validates all the childrens schemas). It may be possible to do similar validation of a "Container" component at runtime. ie Every Container object implements a particular interface that either * exposes metadata about contained components (preferrable) * exposes the contained objects directly (icky) HOwever until we get common metainfo representaiton across all avalon I am not sure the first is an option. Hmmm not sure. -- Cheers, Peter Donald *------------------------------------------------------* | "Common sense is the collection of prejudices | | acquired by age 18. " -Albert Einstein | *------------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
