In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
g writes:
>Added getter/setter for Input/OutputStream
>+ public InputStream getInputStream() {
>+ return _input_;
>+ }
I really don't think these should be public. Otherwise, one might as well
work directly with the Socket class. Callers of SocketClient
implementations shouldn't be able to mess directly with the input and
output streams unless the specific implementation chooses to permit
it (e.g., SMTPClient.sendMessageData). Even in those cases, the streams
are usually wrapped by other i/o classes. To access the streams directly
will bypass the wrappers. I think the methods should be protected,
but since the members are already protected, I don't think there's a
reason to have the methods. At least that's the explanation for why those
methods didn't exist.
As an unrelated side note, the primary motivator for SocketClient was the
lack of support for connection-specific socket factories in JDK 1.1. The
secondary motivator was to put common client operations in one class and
establish a library-wide convention for using clients (e.g., connect,
disconnect) instead of reimplementing them in each class. Now that
there are socket factories in javax.net, there's probably no longer a
need for SocketFactory, but there's probably still a need for SocketClient.
Unfortunately, the NIO stuff doesn't appear to support hooks for
socket factories, so I'm afraid there will have to be some awkwardness
in supporting selectable i/o with SocketChannel and pluggable socket
implementations.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
