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: [EMAIL PROTECTED] http://www.laney.edu/~jim/ as Debian developer: [EMAIL PROTECTED] http://www.debian.org/~jwl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
