C wrote:

> Im not that familiar with it, but PHP doesn't use the same method as 'traditional' cgi.  Typical apache style cgi requires cgi scripts to reside in a designated directory, where PHP does not, just parses and interprets on page load( requiring PHP to be compiled in to apache) .  This is probably still CGI in the general sense but maybe thats what she was refering to ?

The 'new' technologies, ie Apache modules, ISAPI, NSAPI etc, all deal with adding functionality to a web server. In the case of PHP you can run it either as a CGI executable, in which case the PHP scripts would be handled exactly like a traditional CGI script would. This would require them to be world executable, which is why traditionally there used to be a separate cgi-bin. The cgi-bin is however not a requirement, you could install a CGI script/executable anywhere really.

CGI is a standard that deals with the transfer of data from a client to a server. That is, it's the standard that defines what happens with the data that's been sent in a HTML form or suchnot. CGI states that its to be put into environment variables which the CGI application can then read.

With the newer 'module' solutions with dynamic web content served from webpages, I would imagine that the data is not put into environment variables, so I guess you could be right in saying it's not CGI anymore. In the case of PHP though, from the viewpoint of the script, it sees everything as if it were passed through environment variables.

You don't have to compile PHP into Apache, Apache loads it dynamically.

Cheers,
Sigbjørn Lund Olsen

I've been looking into this CGI vs PHP thing lately, and I appreciate your explanations. I've decided that Compendium would not be suitable for mass rationale management for a large open source project. I'm thinking about writing my own system that'll be web-based. From what I've studied so far, it seems that using PHP would be the best approach.

I'm going to move away for a new job, so my oodles of free time have suddenly disappeard. Hopefully I could get the ball rolling on this idea and other people can help me implement it.

BTW, it's "he". :-) It's French (I'm Canadian, not French), and it's pronounced "eh-meal".

Sigbjørn Lund Olsen wrote:
> C wrote:
> 
>> Im not that familiar with it, but PHP doesn't use the same method as 'traditional' cgi.  Typical apache style cgi requires cgi scripts to reside in a designated directory, where PHP does not, just parses and interprets on page load( requiring PHP to be compiled in to apache) .  This is probably still CGI in the general sense but maybe thats what she was refering to ?
> 
> 
> The 'new' technologies, ie Apache modules, ISAPI, NSAPI etc, all deal with adding functionality to a web server. In the case of PHP you can run it either as a CGI executable, in which case the PHP scripts would be handled exactly like a traditional CGI script would. This would require them to be world executable, which is why traditionally there used to be a separate cgi-bin. The cgi-bin is however not a requirement, you could install a CGI script/executable anywhere really.
> 
> CGI is a standard that deals with the transfer of data from a client to a server. That is, it's the standard that defines what happens with the data that's been sent in a HTML form or suchnot. CGI states that its to be put into environment variables which the CGI application can then read.
> 
> With the newer 'module' solutions with dynamic web content served from webpages, I would imagine that the data is not put into environment variables, so I guess you could be right in saying it's not CGI anymore. In the case of PHP though, from the viewpoint of the script, it sees everything as if it were passed through environment variables.
> 
> You don't have to compile PHP into Apache, Apache loads it dynamically.
> 
> Cheers,
> Sigbjørn Lund Olsen

Emile Cormier wrote:
> I've been looking into this CGI vs PHP thing lately, and I appreciate your explanations. I've decided that Compendium would not be suitable for mass rationale management for a large open source project. I'm thinking about writing my own system that'll be web-based. From what I've studied so far, it seems that using PHP would be the best approach.
> 
> I'm going to move away for a new job, so my oodles of free time have suddenly disappeard. Hopefully I could get the ball rolling on this idea and other people can help me implement it.
> 
> BTW, it's "he". :-) It's French (I'm Canadian, not French), and it's pronounced "eh-meal".

Scandinavian 'Emil' is also male, actually.

You might want to look into existing solutions such as sourceforge.org and tigris.org. There are some others too.

Cheers,
Sigbjørn Lund Olsen

Sourceforge has alot of nice features for developing open source projects, but it lacks a tool to do proper rationale management. Its MySQL support seems very interesting for someone who would like to implement a rationale management system using PHP scripts. I'll have to check out tigris.org, never heard of that one.

Sigbjørn Lund Olsen wrote:
> Emile Cormier wrote:
> 
>> I've been looking into this CGI vs PHP thing lately, and I appreciate your explanations. I've decided that Compendium would not be suitable for mass rationale management for a large open source project. I'm thinking about writing my own system that'll be web-based. From what I've studied so far, it seems that using PHP would be the best approach.
>>
>> I'm going to move away for a new job, so my oodles of free time have suddenly disappeard. Hopefully I could get the ball rolling on this idea and other people can help me implement it.
>>
>> BTW, it's "he". :-) It's French (I'm Canadian, not French), and it's pronounced "eh-meal".
> 
> 
> Scandinavian 'Emil' is also male, actually.
> 
> You might want to look into existing solutions such as sourceforge.org and tigris.org. There are some others too.
> 
> Cheers,
> Sigbjørn Lund Olsen