Hi Oleg, >>We have to bear in mind that HttpCore is supposed to be useable without >>any other module. Moving default implementations for connections out >>of the core seems to clash with this goal. > > The default implementations should stay in HttpCore, but they should be > (at least in my opinion) only implement a simple method allowing the > connection to be bound to an open socket. Code aspects that define how > exactly that socket gets initialized (directly or via a proxy) belongs > to HttpConn in my opinion. This is just a proposal. If you object to > such a change it will not happen.
I don't feel well telling our users that HttpCore is useable by itself, but not giving them the infrastructure to open an SSL connection over a proxy (without authentication). Let me ponder this for a while. Opening a plain socket to an HTTP host or proxy is easily enough achieved using standard Java functionality. But that means that applications will have responsibilities on the socket level, while the API works on the HttpHost/ProxyHost level, and we'll have no way to ensure consistency. Maybe we can come up with a small module-conn for opening connections, while HttpConn deals with real connection management, that is pools of connections? cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
