You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@gbiv.com> on 2009/03/18 00:09:39 UTC

mod_fcgid

On Mar 17, 2009, at 3:44 PM, Chris Darroch wrote:

> Roy T. Fielding wrote:
>
>> Done.  I set all of Ryan Pan's commits to svn:author=pqf
>> (for consistency), loaded the whole thing under httpd/mod_fcgid
>> and fixed the eol-style to native.
>>
>> Please relicense the directory and files first before making any
>> other changes.
>
>   Thanks!  I think the relicensing is all done; anyone who wants
> to check for errors will get a thank-you.

I think most of the stuff in NOTICE is documentation that belongs
in README.  The only things we put in NOTICE files are copyright
or attribution lines required by the original copyright owners.

>> After that, we should remove the generated artifacts
>> and consider moving the subdirectory to a module dir under the
>> server trunk.
>
>   Which artifacts are you concerned about?  I'm not 100% sure
> what you'd like done here.

Makefile and .deps should be generated files.

>   I'm +1 on the idea of moving toward inclusion in httpd trunk
> as a module, at least as a longer-term goal.  My thoughts were:
>
> - Start by branching httpd/mod_fcgid/branches/2.x/mod_fcgid based on
>  the current relicensed code, just in case an "emergency" turns up
>  (security bug?) and we'd like to do a release based on the existing
>  code; most likely, we won't use this going forward.

We have not done any releases of this code, so we are not responsible
for "fixing" releases that might already exist.  In any case, a branch
can be created at any time by copying a specific revision number; there
is no reason to create it before the branch is needed.

> - Fix the whitespace; currently if you set your tab stops to 4 chars
>  it looks "right" and close to the httpd style, so it's just a
>  conversion from tabs to spaces that remains.  I've got a reformatted
>  version ready to commit.

Go ahead.  It might be worthwhile to create a tag after the whitespace
changes (same as a branch but without implying later mods) that we can
use for easier functional diffs in the future.

> - Before we can add to httpd trunk, we need to look at the directive
>  names.  There are a large number of config directives with names
>  that don't imply FastCGI and in some cases are a little mysterious.
>  I don't think we can drop 32 new directives into httpd with generic
>  names like "SocketPath" and "PassHeader".
>
>  I have an old patch I can dust off to rename these; we should choose
>  a prefix first, though.  "FCGI" or "FastCGI"?  The latter might
>  conflict with mod_fastcgi, but then, why would anyone run both at
>  the same time?  Still, perhaps "FCGI" is best?

FCGI_ is good.  What about docs?

....Roy


Re: mod_fcgid

Posted by Chris Darroch <ch...@pearsoncmg.com>.
Roy T. Fielding wrote:

> I think most of the stuff in NOTICE is documentation that belongs
> in README.  The only things we put in NOTICE files are copyright
> or attribution lines required by the original copyright owners.

   OK, thanks -- made a quick edit this morning.

> Makefile and .deps should be generated files.

   Agreed; I haven't removed .deps yet because the existing build
process fails without it.  If we're moving into httpd's modules
collection, all this stuff can be scrubbed.  If we're distributing
separately, the module will need a full autoconf implementation.
I'm +1 on the former idea as it saves a lot of effort.  :-)
 
> We have not done any releases of this code, so we are not responsible
> for "fixing" releases that might already exist.  In any case, a branch
> can be created at any time by copying a specific revision number; there
> is no reason to create it before the branch is needed.

   True; I just figured this might count as part of dotting all the i's,
etc.  Happy to skip it if not needed.

> Go ahead.  It might be worthwhile to create a tag after the whitespace
> changes (same as a branch but without implying later mods) that we can
> use for easier functional diffs in the future.

   Done and done, I think.

> FCGI_ is good.  What about docs?

   Docs will take some time, as they always do.  Ryan's original
English docs, which are fairly terse, remain on his fastcgi.coremail.cn
site.  I think it's probably worth taking the time to write a fresh
set and one that covers all the more recent configuration directives.

   Again, this would be a lot easier to do within the existing httpd
doc build framework (even if the docs aren't actually committed until
the code migrates too), so I'm inclined to wait for an agreement on
whether that's the general plan before diving in.  Opinions?

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B