If its a newer version (1.4.x or 1.5.x), did you take GZIP compression option off in
the configuration file? (depending on which version of PSP you use, it will be called
pwu.conf or psp.conf or psp.ini) Gzip compression requires all input is buffered
before displaying output, and going through WebWriteln automates that for you.
In order for PSP 1.4.x and 1.5.x to work fully to its potential it is always
recommended to use WebWriteLn rather than direct WriteLn calls. PSP deals with
sessions (and other things) automatically and needs to know the first time you call
WriteLn. That is trapped for you, when you call webwriteln (but not if you call
WriteLn). When you use webwriteln, PSP gets sent a nice notice that you are starting
the program, if this is the first WriteLn call.
Older versions of PSP allowed you to use direct WriteLn calls, but they had no GZIP
option, and they required a lot more keyboarding than the new automated less
p.s. Also, Trustmaster one of the developers of PSP has already written a small
server of his own in Pascal... I think he put it up on source forge. He used that
with PSP a while back for some experiments.
> i don't know if i will get beat down for asking this question here ...
> but i'll try.
> i found a pascal web server :
> http://www.ritlabs.com/en/products/tinyweb/ >
> it supports CGI suppossedly.
> if i try to get it to use a PSP CGI, the web server renders a response
> that says the CGI didn't return anything.
>in looking at the source, and the CGI examples that come with the
> tinyweb server, their example just does "WriteLn" stuff, writing to
> standard out.
> does anyone know, quick and dirty, if the PSP framework is writing to
> 'stdout' ultimately ?
If you are using GZIP compression in the configuration call, no. If gzip compression
is OFF, then yes, it is writing to STDOUT immediately (WriteLn call)
>sorry for asking here, i just didn't want to have to join another
>handful of lists to get information, if i didn't have to, and i was
>pretty sure there might be some PSP lurkers on this list.
I know the feeling, I think I will combine a bunch of my projects into one list where
people can join. It just doesn't make sense to have 6 lists for 6 small-medium
projects. Better have one instead. Thanks for reminding me of that todo.
> p.s. Also, Trustmaster one of the developers of PSP has already written a small
> server of his own in Pascal... I think he put it up on source forge. He used that
> with PSP a while back for some experiments.
Just for anyone else who is interested.. The PSWS (Pretty Small Web Server)
information is here:
> > p.s. Also, Trustmaster one of the developers of PSP has already written a small
> > server of his own in Pascal... I think he put it up on source forge. He used that
> > with PSP a while back for some experiments.
> Just for anyone else who is interested.. The PSWS (Pretty Small Web Server)
> information is here:
> http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Pretty-Small-Web-Server >
> So yes, we do have a few web servers written in Pascal already.. which is really good
> to hear. A lot of them in Delphi on torry, and some in freepascal such as PSWS.
> i was pretty sure there might be some PSP lurkers on this list.
You have to be careful here, because there are two "competing" projects
called PSP. One is by a Spanish guy (who wrote the Nemesis Pascal
interpreter too) and uses an Object Pascal interpreter to pretty much do the
same kind of thing as PHP, and the other is by an Eastern European guy and
it seemed to me (when looking) was just a way to write CGI in Pascal.
I personally use PSP, but I use the former - which has been greatly extended
by me to support more webservers and also to load plug-ins rather than
staticly linking everything. I'm not clear if this is what *you* are using,
but this is what I immediately thought of. IMO the former is far superiour
as I can change a page in a plain text editor - I only need to recompile if
I want to change the core functionality. The downside - it is Delphi/Kylix
only, as it uses Jedi VCL.
> You have to be careful here, because there are two "competing" projects
To reduce the confusion, let's call Nemesis the "Nemesis PSP project", and let's call
the other one the "PSP CGI project" for now.
They are not exactly competing. The two projects are open source, and they could
actually help each other instead of competing (I don't see any need to compete).
Nemesis is a scripting language, but last time I looked there were no functions
available. The way I understand it is you write your own functions and do all the
work yourself with Nemesis.
What needs to be done for Nemesis is someone needs to write functions that are useful
for web programming, and ship them with the project. If you have made updates to the
Nemesis project, like you say, I think you should upload your work for other's to
use.. have you joined the nemesis project on sourceforge and released a new version
of it with the new functions? It really needs some functions in order to be useful
for serious web programming... Just like how PHP has all those useful functions, you
In fact, there is nothing stopping PSP CGI project from turning itself into a
scripting language. Or, there is nothing stopping Nemesis from using the functions in
the PSP CGI project (either by linking to it via a DLL, or by using the source code
directly). You know how mod_php works? All PSP CGI would need to do is turn itself
into a DLL just like mod_PHP and mod_perl. And that is the plan for PSP CGI 2.0
It's not so much the scripting language or the compiled language you use that is
important.. it's the functions available, that is important. For example, freepascal
would be useless without the RTL. Delphi would be useless without the VCL. PHP would
be useless without PHP functions. It's the functions, that make the base of a
project.. and this is where nemesis needs to improve (and instead of competing with
PSP CGI project, the two projects can combine forces)
In PSP CGI version 2.0, Trustmaster and myself plan to release PSP as a DLL/DSO that
people dynamically link into their programs. In PSP 2.0, you could even invent a
scripting language that talked to PSP 2.0 DLL just like how PHP works. Nemesis needs
useful functions for web programming, so the projects could even borrow from each
other if they really wanted.
In PSP CGI 2.0, a exe/elf should only be about 20-60kb in size since all the major
functions exist in the PSP DLL/DSO and are dynamically linked. So compiling a PSP CGI
2.0 web application will not be a chore to upload to the FTP Server. However, for
those people who really think that compilation is a waste of time.. there is once
again nothing stopping the nemesis and PSP CGI projects from combining forces, and
borrowing from each other. Simply upload the psp cgi 2.0 DLL to the server, and have
nemesis scripts talk to the psp cgi dll. Or, Trustmaster and myself also plan to make
available a mod_psp dll that can be directly installed on the apache server like how
mod_perl and mod_php works.
> called PSP. One is by a Spanish guy (who wrote the Nemesis Pascal
> interpreter too) and uses an Object Pascal interpreter to pretty much do the
> same kind of thing as PHP, and the other is by an Eastern European guy and
I don't see what the nationality or location of the authors has to do with the
of the project. The CGI PSP is being worked on from a number of locations in the
world. Canada, Russia, Europe, and maybe more in the future. As for it being the same
as php? Well once again I remind you of useful functions for web programming. In my
opinion PHP is not useful because it is a scripting language - PHP is useful because
of all the useful functions for web programming. PHP is essentially a CGI wrapper.
And so there is nothing stopping someone from taking the PSP CGI project and turning
it into a scripting language with the Nemesis framework.
> it seemed to me (when looking) was just a way to write CGI in Pascal.
PHP is just a fancy way to write web programs in C. It's not the language that makes
programming on the web easy, it's the plethora of functions available put together in
a certain organized manner. After you have the functions ready, then you worry about
your wrapper. PHP is a wrapper built on top of functions. Nemesis is a wrapper built
on top of no functions. There lies the need for Nemesis and PSP CGI to merge forces,
rather than compete (we never competed in the first place.. only you stated so ;-) )
> I personally use PSP, but I use the former - which has been greatly extended
> by me to support more webservers and also to load plug-ins rather than
Can you put it online for other's to access? Because out of the box, nemesis looked
bare to me. It looked like I could do a "for" loop and that was it. What about
functions for web programming?
> staticly linking everything. I'm not clear if this is what *you* are using,
Statically linking right now. But our base of functions can easily be dynamically
linked when we turn it into a DLL/DSO. In my opinion, build a strong set of functions
first.. then worry about the wrapper later.
> but this is what I immediately thought of. IMO the former is far superiour
> as I can change a page in a plain text editor - I only need to recompile if
Why not follow the same superior tactic with desktop applications? In order to change
your desktop application, all that would be needed is a change in the source file.
i.e. smalltalk, java, etc.
Another problem comes when you want to distribute and sell your applications. i.e. do
you want to try and make a successful business out of web programming, or do you want
your customers to steal your source code from you when you ship it to them? Another
problem comes with security. Large corporations will prefer compiled programs that a
hacker cannot see passwords and source code from. Smaller websites will prefer
uploading their scripts via a text editor. Again, nothing stopping Nemesis and PSP
CGI from combing forces so we get the best of both worlds. I find your message
competitive in tone.. I'd rather combine forces instead ;-)