> From: Peter Donald [mailto:[EMAIL PROTECTED]] > > > > > Peter, what you say makes sense, but how the f**k can you make the > > client specify a hint||constraint with > > > > SSLSocket sslSocket = (SSLSocket)cm.lookup(socketType); > > > > ?!?!?!?!?!? > > ummm ... metadata?
Which is what we've been saying. > BTW there is not a chance that I would suggest that you > directly extract a > resource directly from a ComponentManager. That would suck > unbelievably, > would never scale and lead to all sorts of design > compromises. You aquire a > SocketManager who does the work. Here is the first case of pattern/antipattern. If black magick is not your taste (very few people like it), then we need to come up with a sound solution. We have been harping on the Secure/Unsecure connection as our poster child for multiple types of components for the same function. We already have a ConnectionManager defined. The problem is that is is centered around the *Connection*. Why is this a problem? If it is common for a system to choose whether or not a connection is encrypted or not, the responsibility should not be on the container to do black magick and come up with the proper connection manager. There is too much that can go wrong in this case. The consequences of broadcasting sensitive information over a clear line are too great to fully trust the meta-data model on this case--esp. for military projects where the cost for error might be measured in the life or death of the troops. The better solution would be to change the abstraction so that we can ask the ConnectionManager to return a secure/encrypted connection. In other words, the COnnectionManager should be able to handle the finite possibilities of secure or unsecure (I almost typed insecure, but that is a problem of self confidence ;P ). Changing the abstraction helps in those cases where the choices are finite, and few. In this case we have a choice between a secure connection and an insecure connection. There is no constraint modeling that has to be done. There is no ambiguity as to which component should be grabbed. There is also little chance that a disgruntled assembler could hose your project so easily. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
