Forum OpenACS Q&A: Perl, postgresql in aolserver
Please also see perl+aolserver progress; I have started work on the project, thinking it'll be useful to someone :)
I have since completed basic work on the first piece of the glue (expose Ns_DString to perl on a low level basis). If there is interest, I will make everything I have done on this available.
The AOLserver community, besides being small, is somewhat fragmented right now due to a lack of a (good) central place for the community to gather around.
Your question in the "Ask Phil" forum is probably take long to be answered because Philip is very busy these days.
The best place (right now) for you to ask questions about your "ns_perl" efforts is in the AOLserver list (http://listserv.aol.com to subscribe). Some folks have embedded the Python interpreter and Java inside AOLserver so they can help you a lot.
About the problem sets, if I am not mistaken, someone "ported" them to PostgreSQL, but my guess it that if you're thinking about working for ArsDigita, only Oracle matters, though that could change bocause aD has shown interest is supporting other DBs.
But if you just want to learn the ACS, using Posgres is more than fine. Oh and BTW Postgres des not have OUTER JOINs yet.
Just now, I got an aolserver (which is also running OpenACS) to run a small inconsequential perl-5.6.0 script in response to a browser's request for /perl/hi.
The next step is to implement some of the Ns_Conn functionality and have perl send a web page through an aolserver-browser connection.
If there is any interest shown, I will make the work available.
After doing some of the Ns_Conn stuff, I plan to complete a very efficient and C-like API, exposing it to the perl interpreter.
Once this is done, I will then look into making it more perl-friendly.
- aolserver-3.0 and perl-5.6.0 now joined at hip
- aolserver can call perl scripts
- perl scripts can call aolserver API functions
- perl scripts can load those and other dynamic perl modules
- aolserver passes to perl a connection to the requesting browser
- perl scripts use this connection to send HTML (and others) to browser
- initial release of the low-level API layer planned when completed
- present (messy/un/poorly documented) code can be made available.
Pardon my ignorance about this topic. It sounds like what you're doing is pretty cool stuff.
How can the ability of AOLserver to run PERL scripts help out the OpenACS? Can it?
I'm just curious, b/c i've heard so many PERL fans grumble (".. damn that Tcl, i swear, i'm going to port the ACS to PERL.")
... could this help push them over the edge?!
I'll start with my own reasons...
I've been playing with/learning about the ACS for perhaps 2 1/2 months, starting with a friend's suggestion that I install the pieces of the ACS for a project he is working on. He has since moved it to a different platform, but I'm still here, mostly due to Phil's excellent pedogogical coverage of it. I don't think the other toolkits of this kind have that kind of coverage and I share Phil's belief that kids are the future and should be encouraged, allowed and shown how to create stuff.
I've been doing some volunteer work at a nearby community college, keeping their connection up and creating student accounts. Over a period of maybe 9-10 semesters, I created and maintained the Roster Project, a collection of perl scripts that processes a file downloaded from the school records computer and produces scripts that run on the servers, to assign login/password accounts on those servers. The Roster Project is available under the GPL.
Presently, an admin person needs to know perl in most or all aspects of running the Roster Project, including setup, beginning-of-semester preparation and actually running the student database updates. This is primarily because admins can then look at the data and create scripts to solve problems that come up and partially because the admin has to write some scripts and alter others to customize for his/her site.
I looked into ways to present and allow editing in other ways, but never got around to implementing them, when the ACS came along. I thought, "great, and I can learn it for free if I put the effort in".
So, I dug into Phil's problem set 1, learned TCL, improved on my SQL and got through some of it.
Working through some of the problems, I think I forgot maybe 9 times during a two-week period, that you need
... [expr a + b * c] ...if you want to evaluate any kind of arithmetic expressions. Each time meant 2-3 hours hunting for the problem. When I became aware of this, I realized I didn't like TCL much. The source to some of this was that when you begin a TCL statement, you don't need [ ... ], so TCL compares unfavorably to lisp or scheme, which is at least consistant in this regard.
They say "Strings are TCL's only data structure", but they forgot arrays and lists. They also forgot to make them first-class structures, and that often frustrated me. I was often in the position of returning a set of key/value pairs, especially in books.tcl/books2.tcl.
My summary of this part, is after about 2 weeks of working through problem set 1 and not even getting through (I have more than 20 years of programming experience. I was implementing the FORTH programming language 20 years ago), I find TCL to be typing-intensive, clunky and incomplete, especially in its choice to not make its aggregate types first-class objects. In short: personally, I can code faster in perl, and make deeper things in it. I'm not saying anything about anyone else here, just me. I also want to incorporate the code I already wrote in perl; I can't do that efficiently using CGI for reasons known here. So, I wanted to make perl as close as TCL was to aolserver.
At the point I switched from doing the problem sets to working on the perl interface, I had no clue of perl internals or aolserver internals. With a bit of help and a lot of reading, I was able to take an exposed aolserver data structure, an Ns_DString, and present it to perl as an object-oriented class, with the operations directly mapped to the Ns_DString operations. Once I saw this was possible and played a bit more, I went over to the aolserver side and wrote a way for it to invoke the perl scripts in response to a web browser inquiry.
That brings us to the present, as far as my projects are concerned: aolserver can invoke a perl script (to which it hands off a Ns_Conn object) and the perl script can send stuff (like an HTML page) to the browser.
I think this project can help OpenACS and ACS itself by providing a better scripting language. (And if that doesn't do it, I think scheme should be next :)
The perl people will stop screaming. (well, they will scream less loudly: the API planned now is -very- C-like, very efficient, very close to aolserver and not something a perl coder would be used to. Compare the TCL commands for aolserver with the C api to see the analogy.) Another more perl-friendly API is planned, but its development can't be started (imo) until this "low-level" API is fully functional and available. Given the low-level API as a platform, prototyping such an "outer layer" of the API would be made much easier to accomplish, think about, form new concepts and try them.
Because there is now movement in this direction, the ACS community will get larger. More will be able to participate immediately. I plan for this functionality to be cooperative with aolserver's TCL and to be complete in its implementation of the aolserver API.