Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 38983 invoked from network); 28 Mar 2007 10:41:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Mar 2007 10:41:57 -0000 Received: (qmail 22442 invoked by uid 500); 28 Mar 2007 10:42:04 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 22281 invoked by uid 500); 28 Mar 2007 10:42:03 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 22270 invoked by uid 99); 28 Mar 2007 10:42:03 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Mar 2007 03:42:03 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of david@jetnet.co.uk designates 80.87.128.128 as permitted sender) Received: from [80.87.128.128] (HELO kosh.jetnet.co.uk) (80.87.128.128) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Mar 2007 03:41:55 -0700 Received: from [192.168.1.100] (unknown [89.243.132.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kosh.jetnet.co.uk (Postfix) with ESMTP id B141A28BB4 for ; Wed, 28 Mar 2007 10:40:32 +0000 (GMT) Message-ID: <460A461E.4050308@jetnet.co.uk> Date: Wed, 28 Mar 2007 11:40:30 +0100 From: David Reid User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: dev@apr.apache.org Subject: future of ssl code X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org A while back there was a comment on this list that the ssl code should be "ripped out" before the next release. There was no additional information as to why, but that's OK. Maybe it should be removed into a seperate module along the same lines as apr-iconv? Additionally we should look at what really needs to go into it. There are a few bits of code that I'd like to think about moving into a library with apr's platform independance, but the bloat that is apr-util no longer seems like the ideal landing site. So, thoughts? Comments? Suggestions? FWIW, this will have ramifications for some other code that I plan on working on soon(ish). david