>"UGHHHH... I'm glad you copied my original message text in your reply. I'm
definitely multi-tasking WAY too much today."
Me too.
>"That Delphi/Kylix code is a lot more elegant than I originally noticed.
And far better than the corresponding GetCGIEnvVar method in ConCGI."
Got it - but as you know I'm using freepascal at the moment. I have invested
heavily in it for years at this point.
>"That BufSize and corresponding Buffer are just a first attempt to provide
a reasonably-sized scratch space for any data the OS would return. If the OS
signals that the Env var size is larger than the buffer provided, the
function allocates the correct size and reissues the request. It's PERFECT,
and will handle all your needs for ALL sizes"
Sounds sweet.
>"(provided security is not a concern <g>; Env Vars are a large security
concern...)"
Yeah true, but some believe they are safer than compiled in modules (such as
PHP for multihosted system). Length "limits" for ENV are workable, just not
that 255 char nonsense. My webserver though, after reading your message, I
think I might add ability to filter ENV VARS so that the web master or
application architect has granular control as to which items get stuffed
into the environment. Don't let me confuse you though, my issue is "getting
the whole env var out" inside CGI. I just, as a "webserver author" need to
handle "shelling out" to run PHP for example, and also I have this "CGI"
proxy thing that is a CGI program that actually calls a nother server via
IP, does whatever, and then sends the data back through. It allows for some
cool cross domain AJAX and farming disparate webservers etc.
>"if this code can be made to run under FreePascal. - which, from the looks
of it, and my guess of how FreePascal would attempt to implement things...
should run immediately... "
I will investigate this Kylix/Freepascal combo possibility - sounds neat.
>" This appears to be the way that FreePascal should have implemented their
Windows version of getenv()."
It is open source, I could for example modify it and submit and see what
happens. Many people seem more focused on Linux and I'm no exception lately,
as far as FreePascal is concerned. As far as "windows" is concerned, many
are there too - but I don't think many use the ENV thing like I do so it's
just code that has remained unchanged awhile I imagine.
>" It also wisely uses stack space for its temp vars, instead of the much
slower heap that GetCGIEnvVar uses; or directly loads the longer responses
into the result string."
Interesting. In freepascal (not sure about Delphi) there are these things
called ansistrings.. these are my favorite datatype for doing "scalable"
string manipulations - that would be my goal target "to copy to".
>" And the Linux version of course just returns the whole thing..."
Yup. It's nice.
>" To my knowledge the other functions I mentioned "call the Os for you"
also, they just cap the string length. I don't work with FreePascal at all,
so I wouldn't recognize those getenv... functions from there. They probably
just take the Linux "API"/ OS functions and kept the same names for library
code...
"
I suspect this is the case also on both thoughts.
>" Good Luck with your project"
Thank You very much.
>" if I were you I'd be sure to investigate if there weren't already
existing good projects to work with and/or contribute to."
Instead of what part? My Application/WebServer? Or a CGI "Library"?
>" On the Delphi / Kylix side of things, there are a number, including
multiple systems of code that were sold with the professional and higher
versions of those products."
Losing you about here also - number of what kind of products? I think I will
see the latest offereings of Delphi and try to see what you mean.
Thank you again!
--Jason
From: Wily Dev [mailto:wily...@optonline.net]
Sent: Friday, August 14, 2009 7:05 PM
To: Ararat Synapse
Subject: Re: [Synalist] CGI Blues...
UGHHHH... I'm glad you copied my original message text in your reply. I'm
definitely multi-tasking WAY too much today.
That Delphi/Kylix code is a lot more elegant than I originally noticed. And
far better than the corresponding GetCGIEnvVar method in ConCGI.
That BufSize and corresponding Buffer are just a first attempt to provide a
reasonably-sized scratch space for any data the OS would return. If the OS
signals that the Env var size is larger than the buffer provided, the
function allocates the correct size and reissues the request. It's PERFECT,
and will handle all your needs for ALL sizes (provided security is not a
concern <g>; Env Vars are a large security concern...), ... if this code can
be made to run under FreePascal. - which, from the looks of it, and my guess
of how FreePascal would attempt to implement things... should run
immediately... This appears to be the way that FreePascal should have
implemented their Windows version of getenv().
It also wisely uses stack space for its temp vars, instead of the much
slower heap that GetCGIEnvVar uses; or directly loads the longer responses
into the result string.
And the Linux version of course just returns the whole thing...
To my knowledge the other functions I mentioned "call the Os for you" also,
they just cap the string length.
I don't work with FreePascal at all, so I wouldn't recognize those getenv...
functions from there. They probably just take the Linux "API"/ OS functions
and kept the same names for library code...
Good Luck with your project, but if I were you I'd be sure to investigate if
there weren't already existing good projects to work with and/or contribute
to. On the Delphi / Kylix side of things, there are a number, including
multiple systems of code that were sold with the professional and higher
versions of those products.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public
