Return-Path: Delivered-To: apmail-jakarta-httpclient-dev-archive@www.apache.org Received: (qmail 23903 invoked from network); 19 Sep 2006 14:10:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Sep 2006 14:10:33 -0000 Received: (qmail 20075 invoked by uid 500); 19 Sep 2006 14:10:31 -0000 Delivered-To: apmail-jakarta-httpclient-dev-archive@jakarta.apache.org Received: (qmail 19914 invoked by uid 500); 19 Sep 2006 14:10:30 -0000 Mailing-List: contact httpclient-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "HttpClient Project" Reply-To: "HttpClient Project" Delivered-To: mailing list httpclient-dev@jakarta.apache.org Received: (qmail 19840 invoked by uid 99); 19 Sep 2006 14:10:29 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Sep 2006 07:10:29 -0700 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received: from ([212.227.126.188:57026] helo=moutng.kundenserver.de) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id 3A/C3-27824-05AFF054 for ; Tue, 19 Sep 2006 07:10:26 -0700 Received: from [85.180.0.20] (helo=[85.180.0.20]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1GPgIn1pk9-0007dB; Tue, 19 Sep 2006 16:10:21 +0200 Message-ID: <450FFAE8.2010004@dubioso.net> Date: Tue, 19 Sep 2006 16:12:56 +0200 From: Roland Weber User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060428 X-Accept-Language: en-us, en MIME-Version: 1.0 To: HttpClient Project Subject: HttpCore & connections Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:4601b1d39ab4ddfc21c613822e406392 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi Oleg, I've had some time to relax and think about connections. As a result, I would like to sum up what I think you are trying to achieve. Please have a look through it and correct me where I got you wrong... In HttpClient, the Connection class directly implemented all the functionality that was needed. In HttpCore, the HttpClientConnection interface started out in a similar fashion, providing basically all the methods we expected an application or any component to be interested in. If I got your intentions right this time, you are trying to change that. Instead of a full-blown abstraction for client connections, you want HttpCore to define a kind of adapter interface, which holds only those methods that are required within HttpCore. Defining a full-blown abstraction is left to HttpConn. The responsibility for opening a connection should be moved outside of HttpCore. Hence, the interface does not need to specify an open(...) method. HttpCore does not care where the connection points to, hence the interface does not need a getTargetHost() method. SocketFactory is only needed to open a connection, hence it is not needed in HttpCore. Have you considered ConnectionReuseStrategy? If opening connections is not the responsibility of HttpCore, then deciding on reuse vs. opening a new one shouldn't be either. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org