apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: regex
Date Tue, 15 Aug 2006 15:53:57 GMT
david reid wrote:
> 
> 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.

Just be aware this is a mixed bag.  It won't harm httpd's use, since as you
point out it's already required.  But note that it's baggage aprutil will
have to carry.

We already have too many interdependencies that make building aprutil
binaries for portability near-impossible.

No - don't insert the word 'win32' in the paragraph above, I'm talking about
good old solaris/linux/bsd etc etc etc binaries.  Someone shipping a binary
can either 1. rely on every subdependency in the world, which is alot of
weight to carry or preinstallation to demand, or 2. deploy the minimum
subset required for that application.

> 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.

I agree that pcre is a non trivial problem, so I'm +1 from a usability
perspective.  Name a 'language' that doesn't provide this.

But once you cross the threshold from simple matching to intricate
substitutions, I'm not certain that 'simple' bindings are effective.

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

I think part of the feature-creep paranoia is that aprutil's bindings
just aren't scaling very well.  We need to revisit the modularity of
all these library dependencies sooner, rather than later, and the
resistance to the proposal illustrates this well, as does my earlier
objection to memcached support.  If aprutil provides some finer
granularity, I'd expect much less resistance to new bindings.

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

That's become a troubling pattern, but in all fairness, it's not a bad
place to brainstorm.  It is a bad place to raise and discuss objections,
because you return to the list to discover that other folks also have
the same objection and needlessly repeat yourself.  Plus, future devs
don't gain the benefit of "why was this done thusly?" dialog in archives.

> 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.

Understandable; if folks are interested in this being added please pick
up the baton from David and continue the dialog of adding this code.



Mime
View raw message