From dev-return-14527-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Aug 09 18:44:06 2005 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 40796 invoked from network); 9 Aug 2005 18:44:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Aug 2005 18:44:05 -0000 Received: (qmail 89359 invoked by uid 500); 9 Aug 2005 18:44:04 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 89316 invoked by uid 500); 9 Aug 2005 18:44:04 -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 89297 invoked by uid 99); 9 Aug 2005 18:44:04 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Aug 2005 11:44:04 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [80.229.52.226] (HELO asgard.webthing.com) (80.229.52.226) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Aug 2005 11:44:26 -0700 Received: from [192.168.10.2] (asgard [192.168.10.2]) by asgard.webthing.com (Postfix) with ESMTP id 845E26452C for ; Tue, 9 Aug 2005 19:45:15 +0100 (BST) Message-ID: <42F8F9BA.4080103@webthing.com> Date: Tue, 09 Aug 2005 19:45:14 +0100 From: Nick Kew User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: apr_dbd References: <42F0F44F.9010100@webthing.com> <42F8F58B.4080700@electricjellyfish.net> In-Reply-To: <42F8F58B.4080700@electricjellyfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Garrett Rooney wrote: >> The simple fix to (2) without breaking anything is to retain the >> existing get_entry as-is, and introduce an apr_dbd_get_typed_entry >> defined as above. That would of course be an extra entry on the >> end of the apr_dbd_driver_t struct. > > Can we really do that? Adding an entry to the end of the > apr_dbd_driver_t struct will change its size, and it's defined in a > public header file, so I think that might be against our versioning > guidelines, strictly speaking... Hmmm, really? Retain both source and binary compatibility but can't release? How about if we make a trivial change now by adding APR_DBD_VERSION_PLACEHOLDER /* reserved for future expansion */ at the end of the struct? I'm just thinking how many slots to reserve. If you're happy with that, I'll do the deed. -- Nick Kew