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: Home for apr-based wrappers?
Date Mon, 31 Oct 2005 21:48:54 GMT
Ian Holsman wrote:
> 
> The basic reason is no one has the time/itch to do something like this, 
> and it is usually brought up when someone wants to add something to the 
> core as a way of killing of that. (please don't take that as a flame 
> directly against you Bill)

I'm not - don't worry, I have a long list of emails I was reading this
past weekend from several apr founders, as a basis for my comments on your
contribution.  And I hope you don't take any of my comments on apr_memcached
as a slam against your code - I think it's a great thing, in spite of the fact
that it's out of scope for apr-util.  I'll be proud to have that wrapper hosted
by the apr project in some form.

> I go for:
> 
>   [x]  Strong integration, strong advertising, al la PHP-like everything
>        plus the kitchen sink
> 
> 3. less effort on the userbase's side. While perl's CPAN is fantastic 
> for development, it really sucks when you have to go and build RPM 
> packages around each and every one, check for version incompatibilities 
> between them and hope that there is a mailing list available which a 
> person actively maintains. With a central mailing list I think this 
> would be less of an issue.

One thing this overlooks; this past weekend I tried to integrate current
Qt-Free 3.x (GPL-flavor on Win32) with sip/pyqt.  It gets scary how much
incompatibility results as a large number of libraries are all moving
targets.  My prime complaint against strong/strong is that you *must*
build from source on every target machine, or roll out 2 dozen libraries,
or you are guarenteed to have clashes.  If not rolling out all of the
libraries, that's *not* less effort for users.

> ps. when framing the vote Bill, could you PLEASE use less biased wording 
> in framing your options. This whole note is biased to using wrappers as 
> it was already a done deal.

It's been decided several times that some sort of wrappers would be good
in the long term.  Only action will tell if this happens, but it's nice
for anyone jumping into the effort to know how the entire dev group is
leaning on the issue.  I hope I covered all the essential options (and
obviously, from the apr-commons comment, I left something out) but hope
not to bias the discussion to much for the first day of discussion.

The biggest thing I overlooked in proposing 'some' wrappers collection is;

  [ ]  only offer 'asf blessed' apr (commons style) wrappers,
       don't worry about thirdparty wrappers.

  [ ]  offer the build chain to make apr wrappers easy, but don't actually
       list/provide thirdparty wrappers in our collection

  [ ]  offer asf and off-hosted apr wrappers (al la CPAN) in some central
       database of extentions

which is what the apr-commons comment prompted me to remember.  This part
is really not decided yet.

Bill

Mime
View raw message