On 11/23/06, Niklas Therning <[EMAIL PROTECTED]> wrote:
Trustin Lee wrote: > Shouldn't setSessionConfig() be in IoService rather than in each > IoService > implementations? We could provide implementation classes such as > DefaultSocketSessionConfig and DefaultDatagramSessionConfig. > > Trustin The reason why I didn't add it to the IoService interface is that it wouldn't be type safe. And I can't imagine when you would want to call setSessionConfig() on an IoService reference without knowing the concrete type (SocketConnector, SocketAcceptor, etc) of that IoService. Also, there is no SessionConfig for vmpipe transport so it wouldn't make any sense to have it for that transport (at least not now when there's nothing to configure for vmpipe sessions).
Someone might have received the configuration object and acceptor instance (not knowing it's implementation) from other party. In this case, setSessionConfig() should be provided at least in IoAcceptor/Connector level, and if setSessionConfig() should exist in both interfaces, then it would be better to have it in IoService. But I'm not sure this situation is practically possible. It might be useless as you mentioned. But, I can change it, no problem. It would be more symmetric, since
there's already a getSessionConfig() in the interface. Then we need to do the type check at runtime and we should maybe also provide a VmPipeSessionConfig interface (which will be empty for now) for consistency, right?
Right. DefaultSocketSessionConfig etc would be good. Maybe we should just
rename SocketSessionConfingImpl and DatagramSessionConfigImpl?
Yep. :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
