Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of david@jetnet.co.uk designates
 80.87.128.128 as permitted sender)
Message-ID: <44E1B0B4.6040005@jetnet.co.uk>
Date: Tue, 15 Aug 2006 12:32:04 +0100
From: david reid <david@jetnet.co.uk>
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
MIME-Version: 1.0
To: Garrett Rooney <rooneg@electricjellyfish.net>
CC: dev@apr.apache.org
Subject: Re: regex
References: <44DE3675.5080501@jetnet.co.uk>
	 <7edfeeef0608140701x23c6a9f6ue0c1ff4ab1f1793a@mail.gmail.com>
	 <44E09B56.6070906@jetnet.co.uk>
 <7edfeeef0608141004r219e7812g8e6ea620e0f1d260@mail.gmail.com>
In-Reply-To: <7edfeeef0608141004r219e7812g8e6ea620e0f1d260@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Garrett Rooney wrote:
> On 8/14/06, david reid <david@jetnet.co.uk> wrote:
>> Garrett Rooney wrote:
>> > On 8/12/06, david reid <david@jetnet.co.uk> wrote:
>> >> After a discussion on irc, I've started lookign at adding pcre support
>> >> to apr-util. The patch to start this off is below...
>> >>
>> >> Not perfect and not quite complete, but I said I'd post early on this
>> >> and let others look.
>> >
>> > What's the advantage to using this instead of just using PCRE directly?
>>
>> I've heard this a couple of times now, so while I had thought the
>> benefits spoke for themselves maybe they don't.
> 
> Well, I'd just like to clarify what the goal is here.  Is it just to
> provide an API that's nicer to use in a pool based app?  Is it to
> actually provide a portability layer that uses multiple back end regex
> libraries (seems unlikely).  I don't necessarily object if all you're
> trying to do is make things work better with other apr type code, I
> just want to clarify that it is in fact the goal.

AFAIK libpcre is the main library that people use for regex support, so
I wasn't planning on providing support for anything else. That said, the
interface I proposed does abstract out all the libpcre stuff and so
other implementation could easily be adopted - I just didn't worry about
finding any others.

httpd uses pcre via a wrapper already, so moving it into apr-util makes
a degree of sense right there. Windows doesn't have builtin regex
support, so providing regex via apr-util allows people to write more
portable code. A good thing.

There are places within apr-util where using regex would be useful.
Knowing that I can simply write code that uses regex functionality,
confident in the knowledge that lovely, useful apr-util provides it is
another good thing.

Reducing the dependencies for httpd is a good thing.

Providing an interface that provides more of the libpcre extended
functionality seems like a good thing.

Allowing those using apr-util to benefit from having builtin regex
support is a good thing. Asking them to include yet another library is a
bad thing.

Asking people to learn the intracies of libpcre (not as simple as they
seem as I discovered) to simply use a regex pattern in their code is a
bad thing.

Adding libpcre as a required dependency of apr-util without providing
some way of including the library within apr-util's build (for pcre
challenged systems) is a nasty thing - and one that I'm surprised people
would be happy with.

Most of the above seemed to be self evident, so the high level of
resistance I saw to my proposal surprised me.

The fact that people were happy to complain on IRC but not post to the
list worried me.

Why did I withdraw my patch from discussion? The level of resistance I
saw was quite high and given how many things I'm working on and the fact
that the regex support isn't high on any list of things to be done, I
decided to cut it from my todo list - freeing my time up for other
things. I'd rather be doing productive things than debating pro's and
cons of something that people don't want.

-- 
david

http://feathercast.org/