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.
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.
Oleg Kobchenko wrote:
Good comments, thank you. Here's why
--- Brian Schott <[EMAIL PROTECTED]> wrote:
+ It is proposed to have it like that:
+
I don't understand why -- except for Addons -- the
following are not all Web/... such as:
+ Addons/web/jhp (link to JHP)
+ Addons/web/fastcgi (move FastCGI and SCGI to JAL from Scripts)
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.
+ Guides and Scripts should drop individual references and
+ have one "Web" link under Frameworks in Guides.
+ This is to releave the burden of referential integrity.
+
And why not
Guides/Web containing the part above like Guides/Web/... ?
Is that because of the preference in wikis to have only two
levels?
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.
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
regards,
bill
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
