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 Home for apr-based wrappers?
Date Mon, 31 Oct 2005 18:01:50 GMT
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




Mime
View raw message