On Tue, May 25, 2010 at 2:45 PM, Lee Jenkins wrote:
>
> Not the server computer, but the FCGI application, yes.
>
On Tue, May 25, 2010 at 3:09 PM, Michael Van Canneyt
wrote:
>
> No, just the fastcgi app.
>
And what the "correct" way for do that? Kill the process?
Marcos Douglas
PS: I made IS
On Tue, 25 May 2010, Marcos Douglas wrote:
Hi Michael,
On Tue, May 25, 2010 at 2:19 PM, Michael Van Canneyt
wrote:
You can do this with CGI or FastCGI proxies. It does seem elaborate, though.
How often do you need to restart the FastCGI proxy ? Not often, I would
think.
I never used Fast
Marcos Douglas wrote:
Hi Michael,
On Tue, May 25, 2010 at 2:19 PM, Michael Van Canneyt
wrote:
You can do this with CGI or FastCGI proxies. It does seem elaborate, though.
How often do you need to restart the FastCGI proxy ? Not often, I would
think.
I never used FastCGI. I know it stay in me
Hi Michael,
On Tue, May 25, 2010 at 2:19 PM, Michael Van Canneyt
wrote:
>
> You can do this with CGI or FastCGI proxies. It does seem elaborate, though.
> How often do you need to restart the FastCGI proxy ? Not often, I would
> think.
I never used FastCGI. I know it stay in memory. So, if I nee
On Tue, 25 May 2010, Marcos Douglas wrote:
On Tue, May 25, 2010 at 2:06 PM, Bee Jay wrote:
On 25 Mei 2010, at 23:37, Marcos Douglas wrote:
My only doubt is: why to use CGI proxy, not a FCGI?
The main purpose of CGI proxy existence is to provide solution for some
environments where FCGI
On 26 Mei 2010, at 24:12, Marcos Douglas wrote:
> If the environment allows use FCGI, you would not CGI gateway?
No, because I WANT to use those bonuses. However, by able to use the bonuses,
you can't negate the main purpose of its existence.
-Bee-
On Tue, May 25, 2010 at 2:06 PM, Bee Jay wrote:
>
> On 25 Mei 2010, at 23:37, Marcos Douglas wrote:
>
>> My only doubt is: why to use CGI proxy, not a FCGI?
>
> The main purpose of CGI proxy existence is to provide solution for some
> environments where FCGI setup isn't possible. The other advant
On Tue, May 25, 2010 at 1:58 PM, Lee Jenkins wrote:
>
> Seems a little redundant to me to have one FCGI proxying for another FCGI
> and its not part of the standard either. Lots of sites are using FCGI out
> there with the standard single FCGI server setup.
>
> If you're putting logic into the pr
On 25 Mei 2010, at 23:37, Marcos Douglas wrote:
> My only doubt is: why to use CGI proxy, not a FCGI?
The main purpose of CGI proxy existence is to provide solution for some
environments where FCGI setup isn't possible. The other advantages are bonuses.
;)
-Bee-
_
Marcos Douglas wrote:
On Tue, May 25, 2010 at 12:23 PM, Lee Jenkins wrote:
Personally, I don't see a problem with the static nature of a
apache_mod,ISAPI if you're doing your debugging locally on an embedded
server first and then deploying your executable (apache, isapi, fcgi) later.
That woul
On Tue, May 25, 2010 at 12:23 PM, Lee Jenkins wrote:
>
> Personally, I don't see a problem with the static nature of a
> apache_mod,ISAPI if you're doing your debugging locally on an embedded
> server first and then deploying your executable (apache, isapi, fcgi) later.
> That would reduce the fr
On Tue, May 25, 2010 at 5:11 AM, Bee Jay wrote:
>
> Ok, Marcos... let's take a look at the logic of memory allocation. Everytime
> an app need memory, it requests it to the OS. So, OS always knows which part
> of memory belongs to what app. Once the app is terminated, OS will release
> all the
Marcos Douglas wrote:
On Tue, May 25, 2010 at 4:14 AM, Bee Jay wrote:
On 25 Mei 2010, at 14:06, Graeme Geldenhuys wrote:
I have never looked at FastCGI before, but what you are descibing is
exactly what I wanted to do with CGI. Create a GUI or Service/Daemon
application (application server) t
On Tue, May 25, 2010 at 4:14 AM, Bee Jay wrote:
>
> On 25 Mei 2010, at 14:06, Graeme Geldenhuys wrote:
>
>> I have never looked at FastCGI before, but what you are descibing is
>> exactly what I wanted to do with CGI. Create a GUI or Service/Daemon
>> application (application server) that the CGI
On Mon, May 24, 2010 at 6:07 PM, José Mejuto wrote:
> Hello FPC-Pascal,
>
> Monday, May 24, 2010, 8:43:08 PM, you wrote:
>
> MD> Okay, but if there is not memory leaks...
> MD> I ever free my objects! But I did not know about no memory leaks in
> MD> CGI programs...
>
> There are no memory leaks o
On Tue, 25 May 2010, Bee Jay wrote:
On 25 Mei 2010, at 20:31, Michael Van Canneyt wrote:
But maybe the new garbage collector no longer has the problem; in that case,
my remarks are void.
I hope so. I haven't try the latest SVN either. :D
Tell him he should also get rid of the one-thread
On 25 Mei 2010, at 20:31, Michael Van Canneyt wrote:
> But maybe the new garbage collector no longer has the problem; in that case,
> my remarks are void.
I hope so. I haven't try the latest SVN either. :D
> Tell him he should also get rid of the one-thread-per-session
> model, because it is si
On Tue, 25 May 2010, Bee Jay wrote:
On 25 Mei 2010, at 17:36, Michael Van Canneyt wrote:
Here I can reliably reproduce the memory corruption. It crashes the output
regularly. (with random use, it happens 10-15 times a day, in a test
enviromnent).
Would you share the test code?
Unfortuna
On 25 Mei 2010, at 17:36, Michael Van Canneyt wrote:
> Here I can reliably reproduce the memory corruption. It crashes the output
> regularly. (with random use, it happens 10-15 times a day, in a test
> enviromnent).
Would you share the test code?
> The bug is in the garbage collector, which at
i dont have a win64 machine to test this...
2010/5/25 Bee Jay :
>
> On 25 Mei 2010, at 15:55, Michael Van Canneyt wrote:
>
>> The CGI gateway is on my todo list, as you know.
>
> Now everybody knows. ;)
>
>> Obviously. I think ExtPascal is promising, but sadly suffers from some major
>> design fla
On Tue, 25 May 2010, Bee Jay wrote:
On 25 Mei 2010, at 15:55, Michael Van Canneyt wrote:
The CGI gateway is on my todo list, as you know.
Now everybody knows. ;)
Obviously. I think ExtPascal is promising, but sadly suffers from some major
design flaws (garbage collect, thread model); wh
On 25 Mei 2010, at 15:55, Michael Van Canneyt wrote:
> The CGI gateway is on my todo list, as you know.
Now everybody knows. ;)
> Obviously. I think ExtPascal is promising, but sadly suffers from some major
> design flaws (garbage collect, thread model); which prevent me from
> using it: they c
On Tue, 25 May 2010, Bee Jay wrote:
On 25 Mei 2010, at 15:12, Michael Van Canneyt wrote:
Seems like Graeme is not the only one who is not always listening:
Hahahaha... I know. :D When you point a finger, there are three fingers
pointing back at you! ;)
I said several times before, Fast
On 25 Mei 2010, at 15:12, Michael Van Canneyt wrote:
> Seems like Graeme is not the only one who is not always listening:
Hahahaha... I know. :D When you point a finger, there are three fingers
pointing back at you! ;)
> I said several times before, FastCGI exists since a long time in Free Pas
On Sun, 23 May 2010 12:01:28 +0200, Jonas Maebe
wrote:
> On 22 May 2010, at 21:07, Matthias Klumpp wrote:
>
>> On Sat, 22 May 2010 20:38:59 +0200, Jonas Maebe
>>
>> wrote:
>>>
>>> Actually, yes. The ELF resource writer should probably add such a
>>> section
>>> as well.
>> Should I write a bug
Op 2010-05-25 10:12, Michael Van Canneyt het geskryf:
>
> All in all, I see very little reason for using ExtPascal - if you are
> interested only in the FastCGI code.
At least I knew about FastCGI support included in Free Pascal, and that was
going to be the first thing I evaluate when I get to
On Tue, 25 May 2010, Bee Jay wrote:
On 25 Mei 2010, at 14:43, Graeme Geldenhuys wrote:
My major concern is vendor lock-in. Something we want to avoid at all costs
- we have been burnt too many times. So I'll stay away from ExtPascal
because that requires ExtJS which is a commercial product
On 25 Mei 2010, at 01:43, Marcos Douglas wrote:
> On Mon, May 24, 2010 at 3:30 PM, Leonardo M. Ramé
> wrote:
>> Marcos, nobody is saying that you don't have to destroy instances when
>> programming CGI apps.
>
> Okay, but if there is not memory leaks...
> I ever free my objects! But I did not
Op 2010-05-25 09:51, Bee Jay het geskryf:
> should be able to use the FCGI part only without need to bother with the
> ExtJS part. However, the refactoring result isn't yet fully tested and
> it might leave some coupled code behind.
Good to know, thanks. I'll then take a look at ExtPascal closer t
On 25 Mei 2010, at 14:43, Graeme Geldenhuys wrote:
> My major concern is vendor lock-in. Something we want to avoid at all costs
> - we have been burnt too many times. So I'll stay away from ExtPascal
> because that requires ExtJS which is a commercial product you have to
> purchase (starting at
Op 2010-05-25 09:14, Bee Jay het geskryf:
>
> ExtPascal had been using this technique since about two years ago! I
> told you about this more than once, but you never listen to me. ;) :D
:-) I send lots of messages (too many in fact), so couldn't remember who
told me that. The other thing was th
On 25 Mei 2010, at 14:06, Graeme Geldenhuys wrote:
> I have never looked at FastCGI before, but what you are descibing is
> exactly what I wanted to do with CGI. Create a GUI or Service/Daemon
> application (application server) that the CGI apps talks to. The
> application server would setup the
On 25 Mei 2010, at 11:32, Bee Jay wrote:
> Oh, did I mention live debugging? ;)
Oh, did I mention that FCGI is an open standardized protocol that is supported
by virtually any web servers? That means you could avoid vendor technology
locked-in, such as Apache mod or IIS ISAPI. ;)
-Bee-
_
Op 2010-05-24 18:30, Bee Jay het geskryf:
>
> The CGI app
> (lightweight) will run the ascociated FCGI app (the true app) if it's
> not yet running. If it's already running, the CGI app acts as request
> proxy for the FCGI app.
I have never looked at FastCGI before, but what you are descibing is
Op 2010-05-24 18:02, Leonardo M. Ramé het geskryf:
> Aldo, I know it has templates, the problem I'm facing now is in Windows
> Seven 64bits, It can't read environment/GET/POST vars, so the GetVar
> function doesn't return anything. That's why I had to look elsewere.
Does this only occur in Win7 (6
35 matches
Mail list logo
