Well, technically this could be broken into separate pieces, where what you mean would be given a name like HTTPRequestHandler. However, CGI has long overgrown its narrow meaning of protocol between a web server and HTTP handler and in such form became ubiquitos in major scripting frameworks:
http://search.cpan.org/~lds/CGI.pm-3.25/CGI.pm http://docs.python.org/lib/module-cgi.html http://www.ruby-doc.org/stdlib/libdoc/cgi/rdoc/index.html This could be argued further. If look at the RFC http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html it's not only the command-line protocol, it includes quite a lot of HTTP specifics, which has it's own RFC http://www.faqs.org/rfcs/rfc2068.html But HTTP has more concern over web server details, whereas CGI is more of request handler responsibilities. CGI is ubiquitos and easy to recognize by adopters than other more elaborate naming schemes. And inclusion of HTTP processing into it will not create confusion. CGI is the most practical and likely way J will be used as an HTTP handler. It's the easiest to configure on any platform and works equally well with open source web servers and IIS. Because of jconsole unbelievable startup agility, as opposed to other behemoths like Java or to some extent .NET, CGI is increadibly fast: I can hardly can catch a glimpse of jconsole in Task Manager, unless it's a huge request like generating 16 mega-pixel OpenGL image taking 15 seconds on P4 2.8GHz. Web Services is a different things, which I also was thinking of lately: it'a new COM or socket protocol, which will provide unmatched simplicity to calling J running on a separate machine. I am thinking of having web/service addon for WS protocols and web/xmlrpc separately or as web/service/xmlrpc if it's just one script and there is a lot of code reuse. What I missed is * handling cookies: persistent cookies storage, extracting and generating cookies * encodings could be delegated to other addons in "convert" category * encriptions could be used, also from other addons, such as for cookies or scrambled HTTP (input) params --- bill lam <[EMAIL PROTECTED]> wrote: > IMO CGI framework you proposed is not the same as the CGI protocol that > generally understood. Did you consider choosing another name like > "webservice > framework"? This name is more fashionable and never be a misnomer because > webservices mean different thing to different people. > > Oleg Kobchenko wrote: > > Currently CGI is re-implemented in every different ways > > in-place in various J scripts and frameworks. > > > > CGI is proposed to be implemented as a standard > > general framework and addon to serve the needs > > of all other related areas: Web Server, JHP, > > special apps like Forums Search, other protocols > > like FastCGI, etc. ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
