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