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 <halostatue / gmail.com> wrote in message news:<9e7db91104082120163483bc91 / mail.gmail.com>...
> On Sun, 22 Aug 2004 06:19:08 +0900, Patrick May <patrick / hexane.org> wrote:
> > P.S. <rant> 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