First, I will say this post involves using Perl as CGI. I've seen some Perl communities which tear people apart before the TLA, CGI even gets to the 'G'. I really do not come here often enough to really know if this is one of those communities. Yes, I use Perl for things other than dynamic web pages. No, I realise that any language can be applied to CGI, not just Perl. Please, I would prefer not to hear that stock lecture... again. I basically post here when I am looking for information to everybody's favourite scripting language.
While working on a Content Management System (and a horribly designed one at that), I found that the scripting languages I was using so that I would not have to security check as much as I would before. I had three languages designed... none of them XML based (yeck! (Actually, that is not XML discussion flamebait, it is more to reveal the more active style of the scripts, and that the supporting code is more of a custom thing)). These are mostly to make creating and editing pages using the CMS easier. Perl is a decent language to learn, but the Moshes probably don't want to learn it. I found that putting the interpretors in memory, and loaded, for each CGI call. Something that seems to be a bit much to me.
One of the designs I am going for is, that in the theoretical circumstance that I would happen to get slashdotted, my site would take longer to get knocked off the web temporarily. Another is security.
In this CMS software, I already am having a server pool, set to queue things to various SQL servers that limit sockets (To get rid of the time wasted opening and closing sockets, this keeps them open all the time, and queue the appropiate data to the server). It was only natural to think, maybe make the interpretors their own server.
I could do a quick demo in perl, to tide me over. But, really, that would just be a bad design issue. Then it occured to make the language server in C++. However, the three languages I've designed are not really that... well, not so much advance. One is a Forth dialect (more than anything else), the second is a badly done Lisp dialect (I am thinking of looking at the hyperspec for that), and the last really only is a forum markup interpretor (you know, when you go onto a forum and type b for <b>). This would make the server... well, it could be better.
Now, currently I am working on a compiled language for GBA and SNES, which only requires me to make libraries to match the various hardware specs for SNES and GBA (yes, they may be slightly less powerful than X-station-cube 4, but still nice pieces of hardware in their own right). The language is a Forth dialect that will most likely end up resembling Postscript more than general Forth, which is kind of the plan.
Why is that important? Well doing that has taught me how to look at details in other scripting languages, think of ways that the internals work, and possibly, with more experience be able to make a duplicate. This is what has led me to believe that I could make a server that accepts perl scripts as part of its calls.
It would be done on a threaded basis (think internal *n?x kernel threaded, not the posix libraries), where each script currently being serviced would have a certain ammount of time with each pass, and the next script/symbol_table would be given that much time, looping around, so that if a script did not make it through the first time, it would start off from where it was before. Keep in mind, the version of the *n?x kernel code was from the publishised version of the often bootlegged AT&T UNIX Source Code 6th Edition, Which just might be somewhat dated (might?!?). Generally the interpretor would be seperated from the symbol tables, scripts and data used by passes, and those will be run through interpretors in what should be an shared and effiecent matter.
I would prefer to take a look at the code, but currently am unable to download it (ISP issues), but if worst comes to worse I might be able to do a Perl-dialect for this idea (ew! I know, I know, it would never match up to the shear genius of Larry Wall)
For the client, the client will mostly just be located in the same location as the usual program's shebang, and will just do the appropiate response. I am going to guess that information is sent to the program at the shebang via STDIN. However, it is extremely easy to confirm, but I am on the wrong computer to do that.
This is all nice and such, but then there is security. The only thing I can really think of to do, is (1) limit IPs, with a default to 127.0.0.1. (2) Require some manner of username/password authentication. For username/password, I am haphazarding that if perl normally reads from STDIN, just putting two lines at the top of the script:
#!/usr/bin/perl
# 127.0.0.1
# DakeDesu
# egassemniddeh
or something similar (really, that bit is arbitrary)
The general savings in memory would be for if the perl interpretor was being called and put into memory several times. So, mostly only on a Web Server, would this get decent results.
Yes, there are other technologies that I believe are similar. (Please correct me, but don't hijack the thread about it, please :) )
- .Net (and varients)
- Took me forever to go through the buzzword bingo sites, and just plain marketing to learn that this might be something about a common library system, so that programs can access functions in other languages. I think it also might be able to interact with various other Microsoft products. Does this also centralise the interpretor and try to limit memory usage that way?
- Parrot
- I am going to guess, from what little I have actually read, this is some manner of similar bytecode for various Open Source and Free technologies to run on. Or maybe some manner of scripting language creator?
There is no way that my concept is new, as I think I've heard about mainframes, back before I was even born, running central BASIC servers. So, the major question I am asking is why hasn't it been thought of or done before now with perl? I would be more than happy to work on it myself, but I can tell you right now, it would not even yield anything within the next year or two (which really doesn't impress the Moshes).
|
Re: Perl Server (feasibility issues)
by Zaxo (Archbishop) on May 19, 2004 at 04:03 UTC
|
| [reply] |
|
|
Get mod_perl here as Zaxo says it is what you are looking for, ready to go. Seeing you mention slashdot (who get slashdotted all the time ;-) you may be interested to know they use mod_perl. While you are at it I recommend you to have a look at Apache::DynaGzip which will gzip your content on the fly (static or dymanic) thus cutting your bandwidth use radically as well as making the end user experience better. Most big sites use some form of gzip compression. In case you don't know browsers can decompress gzip streams so (provided they accept it) you send the content gzipped and they decompress it locally. It is a real win-win.
| [reply] |
|
|
Well, I also remembered mod_perl, and well, I just forgot to mention it in the OP.
However, from what little I did manage to gather from the documentation, it appeared to be a method of internal server scripting or a method to write server modules without going into C.
How does Apache know that some scripts are Perl, and others are, I dunno, python, bash, tcsh, or just about anything else somebody would be silly enough to mix in with Perl? Does it check the shebang?
I guess the main thing would be that I did not wish to rely on a single piece of software to have this work with. Though that is curable by a simple switcher script (if feature is available, use it, if not, don't use it)
Also, other than ye' ol' RTFM, what articles, places on the web, what have you, are there to learn about mod_perl? As maybe shown above, previous attempts left me... well not that decently knowledgable
| [reply] |
Re: Perl Server (feasibility issues)
by rjray (Chaplain) on May 19, 2004 at 04:44 UTC
|
.Net is only effect inasmuch as you can run the languages you want to under the CLR (Common Language Runtime). There are several languages to choose from (including a few environments that support Perl). You might want to have a look at the Mono project: http://www.go-mono.com.
| [reply] |
|
|
I looked in the languages section, and did not see Perl as a supported language. Though, from what little I've gathered, that appears to be what I want to work on.
Though, I would need to get a feel for it... are there any places, other than straight RTFM, that I could possibly play with languages that are already there? Just to get a feel?
| [reply] |
|
|
There isn't any Perl support within the Mono project per-se. However, there's a dotPerl effort that someone mentioned on one of the mono mailing lists a week or two back, and there is also a Visual Studio.NET module/plug-in of some sort that ActiveState makes. Since these would ultimately produce .Net assemblies, you could then use them under a Mono system. However, both tools (as far as I know) would have to be run under Windows environments that support Visual Studio-level development (i.e. W2K or newer, excluding WinME).
| [reply] |
|
|
Re: Perl Server (feasibility issues)
by simonm (Vicar) on May 19, 2004 at 14:50 UTC
|
In this CMS software, I already am having a server pool, set to queue things to various SQL servers that limit sockets ... It was only natural to think, maybe make the interpretors their own server.
There's an existing standard and supporting libraries for this, in the form of FastCGI. If your CMS can support the FastCGI protocol, than you can talk to existing applications written to use FastCGI in Perl and many other languages. | [reply] |
|
|
Hmm... I've seen FastCGI in various software lists, but was given nothing as to its nature. I am also spotting a nice consistancy in my posts in this thread.
That is lack of eduction, or lack of advertisiment. About the only thing I see close to this in various linux magazines is maybe a quick article comprising mostly of links to online places to something that seems... well... I have a lot of reading to do, for things I found on my own.
I just need a starting place for FastCGI. (Which Perldoc will be checked well enough)
Perhaps Open Source and Free Software movements need to up their advertisements?
Too little known, so much to read up on.
| [reply] |
Re: Perl Server (feasibility issues)
by flyingmoose (Priest) on May 19, 2004 at 17:39 UTC
|
Though mod_perl is indeed what you want (besides, well, your ideas being a little goofy, but that is ok -- insanity is useful, I should know), if you are interested, the excellent webmin contains a (quite workable) web server completely written in Perl. As a result, webmin does not require apache or any other web server to work. You could read the code if you like, I'm not sure if it's good Perl or not, but it's something to read. | [reply] |
|
|
It is not so much a server in Perl that I want to create, it is more of a server to read Perl, and various other languages too. Just so in the features list (AKA Bugs AKA Lies), I can mention something about scalability and expandability and various other Buzzwords.
The software itself, as a goal, should require that as little be install on the target platform as possible. Well as little outside the range of software behind this CMS.
| [reply] |
Re: Perl Server (feasibility issues)
by mattr (Curate) on May 20, 2004 at 07:07 UTC
|
Thank you for the wierdest post I've had the pleasure of seeing in a while. I just had to log in to say that. I also think you want apache with mod_perl. This will load the interpreter just once on server restart, along with any modules you specify in apache's httpd.conf file and a startup perl file you specify. You really don't want to make a web server in Fortran, Lisp, C++ or Postscript, or whatever.
Unless I failed to penetrate your post, you do not need any other languages. The point of your project seems to be a public application or messaging server with a content management backend, all of which can be built on great perl modules, see the Comprehensive Perl Archive Network at cpan.org and turn yourself loose on all the resources that are available there. I also recommend the CGI::Application module which may help you keep things organized..
Mod_perl is basically a perl interpreter bound into Apache, which makes each child process bigger but the total is much better performance since you do not load interpreters all the time. You can actually run perl CGI programs on it too though. Mod_perl programming requires that you program cleanly, since globals can get carried across processes. However I built a search server that calls a C++ based program (htdig) and benefits a lot (security, prototyping, pluggability, management console, massaging output) from the mod_perl part and consistently provides results in tenths of a second. Also if you program with "use strict" you can probably convert your CGI to MP immediately when you move to an ISP that provides MP.
The rest of what you are talking about is probably Parrot which is still being developed, which you can learn about for yourself online. But you do not need Parrot (or .Net for that matter) for your CMS. If you do need to execute say Java or something else you can undoubtedly call it from your mod_perl program, but I do not have experience in embedding say inline Java (these perl modules exist) in such an environment.
You may wish to study the apache manuals since this will explain how you specify handlers in the httpd.conf file to direct files with certain suffixes, or in certain folders, to be run with a given handler. It also tells how to control access by IP if that is what you want, though there are a bunch of apache/perl modules that can do authorization against databases and so on. I used mysqlauth on apache 2 (not there are different versions out there) with success. I recommend you start small and once you get something working add on to it.
As for Perl-based servers this is another possibility, but it is not clear if it will be as bulletproof or more so than apache. Why not experiment with a couple of different ways first. | [reply] |
|
|
I'd like to thank you for your nice description on mod_perl. I probably will not be attempting the whole perl server now that I know what is going on with mod_perl.
Though, just note, as the confusing is still there, it was not a web server I was thinking about making. If anything the default was to only run over 127.0.0.1 (or ::1), and allow for other IP addresses to be added. The client would send a perl script to be ran under a certain username:password sort of pair. The script would be ran, and STDOUT&STDERR would be returned to the client.
Oh, and as for the weirdest post... I was mostly trying to get thoughts and feelings down--think of it like a core dump from my mind.
| [reply] |
|
|
Hi,
Thanks for your reply. That's cool, I hope it was of some help. I'm not sure how the stderr etc. get returned, I was saying >2&1 or whatever you write in bash to redirect (merge) stderr to stdout, and write to a file, but I did do massaging of web page outputed by c++ program so that much is certainly doable. I forget how I did it, you use backticks or also there is a module to do it too I believe, see the long mod_perl manual on the big mod_perl developers site. Good luck!
| [reply] |
|
|
