[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ANNOUNCE: Project to weld a specially-built perl-5.6.0 to aolserver



Hi,

(please NOTE crosspost. I presently think discussion should take place on
-devel for awhile then move either to -perl or to a web-based list; I'm
open to suggestions on this.)

I have been working on a project to bring aolserver and perl together for
the past 2-3 weeks, and it has passed what I consider to be all its proof-
of-concept stages: with the preliminary code I have written, an aolserver
which receives a request from a browser can respond by running a perl script.
The perl script can then send content back to the browser. 

A statement of progress in a bit more detail can presently be found at

  http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0000Tb&topic_id=OpenACS&topic=

In my opinion, this makes the project a success as it stands. However,
aolserver's API presents a very rich, complete set of functionalities
that can be exposed to perl. This includes very efficient connections
to databases that remain open, so a perl script would pick up a connection,
make SQL queries which load into variables or arrays thereof and then
return the still-open connection to the pool.

My plan is to provide two APIs, an inner, low-level layer representing
a very direct, complete and verbatim representation of the API that
aolserver exposes in C. Once this layer is complete, a second layer
will be built on top of that to provide a much more perl-like interface.

Presently, help is requested for the low-level API for pure coding and
copying documentation from aolserver's site into perl's "pod" (plain ol'
documentation) format embedded in the code.

If you have some experience writing perl extensions in C and adding
embedded POD-style documentation and you would like to help, please
reply to this email, and I'll get you started by showing you how to
build what I have now. 

The extensions are fairly easy to make, and the documentation can
almost be copied from the site: the license allows, and the argument
lists will be very close to the C API.  So editing is minimal, and
each XS function will require almost no additional code. Because you'd
have a working version of the infra- structure, you can test each
function immediately after writing it. For data-structure packages,
I will supply new and DESTROY; you will have them before you start in.

I'm not sure what I want to do about releasing what I have now. The
code is very preliminary and I don't want a release thereof to make
too bold a statement about it. However, anyone who wants it can have
it. If I get innundated with requests, I will put the code somewhere
central and post here as to its location.

Until this layer is done, -no- help is requested for the second layer,
nor are ideas for making it easier for perl coders. The only thing I
want to work on now, is the low-level layer, as verbatim as possible
with the API exposed by aolserver. The data structures are to remain 
opaque, they get explicitly allocated, and they do not get converted
to familiar perl data structures. The second layer will address all
such conversions in as transparent a manner as possible.

HOWEVER, -please- hold onto your ideas and write them down. Once the
low-level layer is complete, it will be released, and I will open up
to analysis, design, development, implementation and documentation of
the final "outer" layer. My reasoning behind this separation, is it
will be best if the entire API is available in perl in some form so
that prototyping can easily occur.

With any luck, the inner layer will take 2 months or less, and thinking
about the outer layer can begin once the inner layer is complete.

-Jim

---
Jim Lynch       Finger for pgp key
as Laney College CIS admin:  jim@laney.edu   http://www.laney.edu/~jim/
as Debian developer:         jwl@debian.org  http://www.debian.org/~jwl/


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: