Hi!
The decorator stuff seems really cool to me. :)
However, I'd vote for supporting proxyHost and such, because there are a
lot of legacy systems out there moving to MINA. When they finally
migrate to MINA, their users don't really want to know about the change,
and don't expect changes in the configuration of the system.
I think all of these systems will then create something like
LegacyProxyConnector inherited from ProxyingConnector, and set the proxy
parameters from proxyHost etc. As I think a lot of people would
implement this redundantly, MINA could have it out of the box as well.
Regards,
Lóránt
Maarten Bosteels wrote:
I agree with everybody else that the decorator pattern is an elegant solution.
About system properties, I agree with Trustin: I don't think we should
support that.
Maarten
On 10/2/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
On 10/2/07, Niklas Therning <[EMAIL PROTECTED]> wrote:
Yes, I think this is the way to go about implementing this kinds of
things. This is similar to what was suggested the last time the proxy
issue came up on the mailing list
(http://www.nabble.com/Proxy-filter-tf3880454.html).
How did you find that thread? :)
Now, one thing we should consider is whether we want to support
specifying proxyHost, proxyPort via system properties, just like Socket
does. In that case I don't think it will be as simple as wrapping like
suggested above. Maybe we could support this by having some kind of
factory which looks at the system properties?
I agree with you that things will get complicated with system
properties. The questions is, do we really need to support system
properties? If a user uses a factory like Spring, he or she could
configure proxied connection very easily.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
