From: paul@... (paul vudmaska) Date: 2004-09-04T16:55:18+09:00 Subject: Re: Idea: Webshare / cgi Seems to me there is good reason to seperate response from request, for historical reasons as well as practical/semantic ones. Seperating data coming in from data going out seems good enough reason to me(and I also don't see the code redundancy between them). Coming from the m$ asp world, cgi.rb was the one (of very few) big burr in my side. Going back to asp of late has been comforting in that respect (if only that! i want my dbi,rexml,interpolation,heredoc,dynamic includes... :). I'd wager that if ruby's cgi were implemented in similar fashion there would be far fewer posts(from experienced and inexperienced coders) on here regarding it. //data in - this aint an array unless i want it to be sform = Request.Form('var') // overrides Url surl = Request.Url('var') //asp uses querystring..too long Session('var') = surl //cant remember how to do that in ruby but it aint clean. //out Response.Write(Session('var'))//puts works but this is more readable All that seems obvious/transparent to me. It is tried and true method(at least the distinct request/response) in every app server i've used (cold fusion,asp,zope,.net,jsp...). To me, these things are fundamental and wont be easily(or elegantly) extricated from the basic workings of a web app - data in - data out - that's what we do as web developers. As far as an abstraction layer for backend data, that would be a huge win for the ruby web crowd. Setting a var that would allow me to say... hold session vars in a db rather than in ram or a file would be great. I realize the new version has memorystore/pstore etc. Whichever one you use, the implementation should be the same or similar. What about application variables? Did i miss them in my ruby adventures? I sure like/use them in asp/cf. All web app servers i've seen have caching mechanisms baked in deep and getting deeper. Seems to me much could can still be learned from other mature web app servers. Like them or not, each of them have their wins and warts. Ruby's cgi is a wart,imo (and i truly mean no dis to the guy/gals[s] who wrote/write it - i run across few with that level of programming skill in my world - i just dont like using it) Asp's implementation of cgi is the best i've used. So there, i said it ;) peace Austin Ziegler wrote in message news:<9e7db91104082120163483bc91@mail.gmail.com>... > On Sun, 22 Aug 2004 06:19:08 +0900, Patrick May wrote: > > P.S. About the only cgi design suggestion I see on ruby-talk > > that I outright disagree with is Request / Response. > > > > I experimented with this in Narf, and I think it is a mistake. You end > > up with two objects, with alot of shared implementation code, that > > always go together, split apart for no practical reason. I don't mind > > having Request / Response separated in the documentation, but splitting > > it in the code just adds typing. When will you ever want a request > > without the response? Martin Fowler has a name for this refactoring, > > but I don't have his book. > > As someone who thinks that a request/response is a good thing, I'll > first agree with Andreas that while they may share implementations, > they don't share data (which suggests a Request class, a Response > class, and a "Message" class). Separating request and response, to me, > is as simple as the splitting of STDIN, STDOUT, and STDERR. In theory, > I could choose to request from one computer but respond in a different > location -- why should I be restricted to responding to the person who > made the request? (Granted, I can't see why I would do such a thing, > but who knows whether such a feature would be useful?) > > -austin