--- bill lam <[EMAIL PROTECTED]> wrote: > FWIW FastCGI and SCGI protocols are designed to be source code compatible > with > CGI. Theoretically all CGI scripts should be executed correctly using > FastCGI/SCGI by linking to a different library or using cover function for > stdio. All CGI environment variables are available, furthermore Scripts for > FastCGI/SCGI do not need to know anything about socket programming. So I > think > that FastCGI/SCGI is as general as CGI and should be placed parallel to CGI.
Only CGI command-line protocol is parallel to FastCGI/SCGI. But since we established generality of web/cgi to handle HTTP request processing, CGI and FastCGI/SCGI overlay only in the thin part related to the booting the handler: from jconsole for CGI and via sockets for FastCGI/SCGI. The rest of the HTTP handling should reside in and be reused from web/cgi, from decoding of parameters to generating headers, encoding output etc. > My FastCGI/SCGI server script is just a simple demo. There are http server > testing tools such as ab, http_load to show how naive and unreliable it is. > AFAIU JAL is meant for production code, so that I feel the demo script does > not > fit into JAL yet. > > Of course, FastCGI/SCGI protocol is reliable, only my demo server is not. Yes, in general JAL would maintain the standards of quality code, but it's not limited to polished API modules, especially at the initial growth stages. It is sufficient that the code is working, of interest to other users, covers an interesting technology, or otherwise has value to be preserved or re-used. If the code does not warrant a separate addon, typically being just a simple one file script, it is placed in the misc folder under the appropriate category. By JAL design, this is meant for most of the code in Scripts and Guides wiki pages. It is acually encouraged, since the wiki attachment or inline code storage an inconvenient and has no version control. Exceptions are small code snippets for copy/paste, which can be held inline. In fact, dependency of FastCGI/SCGI on web/cgi has a few advantages in terms of the JAL coding practices - promote code re-use of the standard web/cgi addon - validate its feature completeness - be a good example to other addons and applications > Oleg Kobchenko wrote: > > Addons/category/addon is a standard location for the addon > > reference page. It's enough for one-page reference. But > > for multipage reference, typically the case for frameworks, > > like format/publish, it's best to put them in the root. > > > > All below > > > >> + CGI/... (new standard general framework) > >> Web/CGI/... (new standard general framework) > >> > >> + JHP/... (new framework) > >> Web/JHP/... (new framework) > >> > > except > > > + Web/FastCGI (move from Guides) > > > + Web/SCGI (move from Guides) > >> + JWebServer/... (framework - leave as is) > >> Web/JWebServer/... (framework ) > > > > are frameworks, actually FastCGI and SCGI *could* > > be put under CGI. But I want CGI to be strictly > > the J framework as described in > > http://www.jsoftware.com/pipermail/general/2007-January/028600.html > > where as FastCGI and SCGI could be limited to socket > > protocol and themselves use J web/cgi addon. > > The reason of limited level of nesting is one, then > > simplicity and useful composit names like [:Web/FastCGI], > > which do not require separate cover names like > > [:Guides/FastCGI:FastSCGI Guide], but mainly it's > > semantical. It shows that Web is a very important area > > that will contain many different topics in itself > > and reference frameworks. ____________________________________________________________________________________ Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
