Berin, I didn't read this before replying to your previous mail. I introduced a few ideas that address some of the same issues you've discussed here, but I hope you also consider my suggestions.
(: A ;) Berin Loritsch wrote: > Berin Loritsch wrote: > >> Antti Koivunen wrote: > > >>> Is it intended to replace CM/CS? >> >> >> >> IMO Yes. > > > At least on a smooth migration path > > > Please take a look at the Resolver package with an updated API. The > API reflects Antti's well thought out responses. > > > >>>> Please, I am soliciting feedback on the proposal, so we can see if it >>>> fits all our needs. >>> >>> >>> >>> A few ideas... >>> >>> 3. I would consider string (e.g. URI) lookups in addition to the >>> heavier Query structure. Some examples: >>> >>> uri://domain.com/services/UserManager >>> >>> uri://domain.com/User?id=42 >>> uri://domain.com/User[lastName=Doe,firstName=Jane] >>> >>> Service:type=UserMgmt,country=FI (JMX style) >> >> >> >> Sounds reasonable > > > Looking at this in more detail, it looks as if it can replace the need for > the Excalibur Resolver package as well as the differentiating between > Component/Service/Object/etc. I like this approach, and even changed the > Query object's interface to reflect the URI approach. > > > >>> (All of these could be represented with an object, if necessary. See >>> e.g. javax.management.ObjectName) >>> >>> 4. In Token: Object[] references() -> Iterator references(), not to >>> restrict the implementation (e.g. in case there are MANY references). >> >> >> >> There shouldn't be *that* many references that you retrieve at one time. >> In practice, I have not seen more than 5-6 external components used. >> Even then, that is bordering on being too coupled. > > > I added this as another alternative (along with a simple Object return > value for the more direct resolve uri approach) > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
