> > 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. >
Thank you for putting this so eloquently, to back it up with the most simple example of all though.... remember images, that a majority of web sites use these days, are distributed over that very protocol right under our noses! There is a realization to make here that some of us have become so used to the "it just works" model of web development that we even begin to think of things such as images that come down over that same big pipe as actually being part of the actual page, rather than a completely separate request/response/session! Even if we aren't talking about all those web service things, this is the best reminder that what travels over HTTP need not be HTML-esque. http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
