> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > > > > Which you could do as: > > > "urn:NID:NSS" > > > "jini:<jini lookup info>" > > > "role:<role-descriptor>" > > with a single interface exposed to the invoking object. > > Theres already a framework for that - JNDI. > > <<grin>> You noticed that, did you. :-) Having written both > JNDI clients > and JNDI service providers, it wouldn't bother me to use JNDI > as a standard. > It is a bit of overkill, but I could live with it. However, > since it can > impact the ability to get small, my thought was to limit the initial > requirement to the composite name lookup aspect, which is > fairly trivial to > code (and delegate).
This is a point we agonized over in the past. JNDI has the benefit of being #1 a standard and #2 familiar contracts. It also has the ability to be quite resource intensive depending on what is going on behind the scenes. Beyond the heavy-weight argument, there are a couple other reasons why we finally decided not to go with JNDI: * No clear separation between obtaining a reference to a service or data. * Precludes effective J2ME programming (phones do not have near the capacity as a PDA--although they are getting more powerful). * The biggest reason is no IoC. The container has to set them up statically, and either run components in separate threads or unify the namespace. In the end, the only way to have a separate namespace for all the components would be generally unworkable in the real world. I'm sure in the archives you will find a very interesting debate between Peter, Fede, and I on the topic. In fact, Peter and I managed to convince each other so well of the other person's viewpoint that we flip-flopped positions once or twice. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
