apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <...@holsman.net>
Subject Re: Home for apr-based wrappers?
Date Mon, 31 Oct 2005 21:20:19 GMT
This is all fine and dandy, and has been brought up multiple times before.

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)

but to your vote.

I go for:

   [x]  Strong integration, strong advertising, al la PHP-like everything
        plus the kitchen sink

BTW you forget some of the advantages of strong integration:

1. I know that the code exists, it doesn't rot away on some sourceforge 
page. which means I either write my own (cost) or don't see the 
possibility (bigger cost)

2. It sends a signal that APR (and the ASF) believe the code is good, 
and worth using. This is very important, as while most people would be 
comfortable using APR/HTTPd. they would shy away from using a little 
2-person sourceforge project.

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.

4. common look & feel to the API's.

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.


William A. Rowe, Jr. wrote:
> Some interesting wrappers to the 'apr model' of development have been 
> created,
> and more will undoubtedly follow.  These are distinct from apr-util in 
> that they
> don't provide portability (target a single platform or library package).
> Consider some examples, such as Perl's Crypt::SSLeay class, or Python's 
> PyQt
> package.  Nearly all of these extentions are in the core distribution, 
> but are
> layered on either by packagers or end users.  Most every language authoring
> group has set down a line for what the crux of their core package does 
> right,
> and leaves the rest for independent developers and implementors.
> Who distributes these add-in's for various languages?  Some solutions like
> CPAN are part of or closely integrated to the language project itself.  
> This
> can even go overboard, al la PHP, which attempts to distribute them all 
> (and
> is often broken w.r.t. specific libraries or add-in's).  Others ignore the
> issue and entrust the users to create networks of add-in facilities, and 
> for
> users to spend time in google seeking out their answers.
> Finally, some packages forsee the interest of users to link that library 
> into
> php, perl, python, C or whatever languages, and provide the bindings 
> themselves.
> In any case, because of the modular nature of these add-in's - the core 
> language
> project doesn't bind users to a single implementation, and doesn't chase 
> the
> quirks of that library's latest release upon each of their releases.  
> External
> dependencies of the core package are minimized, and these add-in authors 
> chase
> the latest library and language core releases to keep it all in sync.
> I'll give one small example, ap_regkey in httpd 2.  It's a very 
> apr-style Win32
> registry accessor.  But it's meaningless in other platforms, and 
> therefore did
> not belong in apr or apr-util.  Would this package be useful to others?  
> Quite
> probably.  Another recent example is obviously apr_memcached.  And it's 
> been
> suggested apr_serf, apr_el_kabong (html parsing) and others that didn't 
> quite
> pass the apr project's threshold of portability.
> SO...
> What sort of home should the apr project adopt, in order to leverage all 
> the
> interesting things that can be implemented as coherent apr packagelets?
>  [ ]  Strong integration, strong advertising, al la PHP-like everything
>       plus the kitchen sink
>  [ ]  Weak integration, strong advertising, a CPAN-like repository of
>       everything, individually obtainable and installable
>  [ ]  Strong integration, weak advertising, e.g. a comprehensive set of 
> build
>       tools to ensure modules are all using the same build schema, al la
>       Perl's Makemaker or python's setup.py strategy
>  [ ]  Weak integration, weak advertising, al la no official apr collection
>       or database of wrappers.
> and one more obvious question;
>  [ ]  Individual wrappers to permit a new add-in to be compiled quickly
>  [ ]  One honking huge aprwrappers.so module
> Since we will continue to be haunted by these, either infrequently (because
> few are finding apr interesting for extensions) or more and more frequently
> (as more developers try to create real world apr-based solutions) - it 
> seems
> time to finally deal with this.
> Bill

View raw message