Garrett Rooney wrote: > On 8/14/06, david reid <[EMAIL PROTECTED]> wrote: >> Garrett Rooney wrote: >> > On 8/12/06, david reid <[EMAIL PROTECTED]> 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/
