On Thursday, Nov 6, 2003, at 18:55 US/Pacific, R. Joseph Newton wrote:
"NYIMI Jose (BMB)" wrote:[..]
One reason to not use CGI.pm:
An important concern today in the integration architecture is to provide a means to support different type of clients. Unfortunately CGI.pm will not fulfill the increasing requirements to support clients expecting other format than HTML. Such clients can be palm top computers, mobile phones or other device that enables client access.
Hold it! We are talking about CGI work and the Web. The web is defined as the set links that connect html pages to each other. For other programming or iInternet communication tasks, you certainly would find other functionality more appropriate.
actually, if we want to be pedantic, CGI ( common gateway interface ) as opposed to say 'computer generated images' - is a set of 'rules' about how a "web_server" will broker deals with other code. It will set up certain envrionmental variables, and pass information to that code in a given manner. It will of course 'return' anything sent to it over STDOUT to the original caller.
When we remember that the "web_server" is merely an 'httpd' - a daemon that knows how to 'cope' with "HTTP" as the session layer, then one has that 'coffee break moment' that there is NOTHING in the HTTP spec that mandates the 'content' of an HTTP message. the fact that so many folks have become 'attached' to the idea that it is about 'HTML' is, well, a cultural artifact and not a part of the actual spec.
As such, it IS perfectly legitimate to use HTTP as one's session layer, and hence to have CGI code that IS NOT about passing HTML around. If anything that is a part of the amusement of Jose's core position. A point that folks who view 'web services' in the limited image of being merely about 'web browser' based 'html' technology tend to ZONE OUT.
Granted getting one's head out of the limitations of HTML as a 'mark up language' can be hard for some folks - but it IS something that folks need to wake up, smell the coffee, and get on with what is IN the HTTP spec, as opposed to the various "DOMs" for HTML/XHTML, and that CGI ( common gateway interface ) itself does NOT mandate the 'content' that the 'deal' is brokered in between the 'httpd' and code invoked!!!
At which point, one really can decide if one wants to use the CGI.pm module to simplify things, or whether the parameter picking process is simpler done with one's own tailored parser.
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]