On Sun, Aug 11, 2013 at 06:25:11PM +0200, Stephan Beal wrote:
> On Sun, Aug 11, 2013 at 6:10 PM, Richard Hipp <[email protected]> wrote:
> > On Sun, Aug 11, 2013 at 9:20 AM, Stephan Beal <[email protected]>wrote:
> >>
> >> That wasn't terribly clear. FastCGI basically starts 1 instance of the
> >> app and keeps feeding it new data for each request. Fossil's structure does
> >> not allow it to do that.
> >>
> >>
> > Does too.
> >
> > For Fossil to run FastCGI/SCGI, all that is needed is another command
> > similar to "fossil server" or "fossil ui".  The "fossil server" listens for
> > incoming HTTP requests and responds separately to each request.  A "fossil
> > fastcgi" or "fossil scgi" command would do basically the same thing, except
> > that it would interpret the FastCGI or SCGI wire protocol rather than HTTP.
> >
> 
> It _can_ do that but that negates the benefit of using fastcgi because
> fossil ends up forking anyway.

It's not much of a benefit if the alternative is that you can't use
Fossil with that particular webserver anyway.  If I chose to use nginx,
the reason wouldn't be to prevent myself from using CGI.  Of course,
that's speaking from the perspective of what I'm trying to do.  Your own
circumstances, as you described in parts of the email I snipped out,
were apparently more about specifically wanting FastCGI.

I'm actually leaning more toward thttpd now, anyway.  Of course, setting
up a webserver that would interact with Fossil is somewhere in the
future at the moment, and it's not really a critical decision at this
time.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to