On Fri, 28 May 2004 07:10:03 +0900, Aredridel wrote

> It's good for URL migration, and for filtering namespaces -- if I
> implement an app that, say, is a web-based editor, I can see it being
> very useful to "reparent" the entire namespace transparently into a
> sub-space --
> 
> if /foo.html and /bar.html are the normal namespace, it would be 
> nice to implement a filter so that /baz/foo.html maps to the 
> original foo.html, it would be nice to not have to recode any 
> absolute links in the files.

K.  I think I follow you here.  
 
> > new_page = registry.application('wiki')
> > new_page.page = 'HtmlTemplates'
> > yield new_page
> 
> Ooh, nice.

Yeah.  Now, the actual implementation....I've got to think about that a lot 
more.
 
> Making it RPC-based isn't a bad idea, so it would work across servers
> (Aha! Web-enabling web applications! A novel idea!)

I'm liking the implications of how applications could flexibly interrelate 
the more I think about it.  Going to be sitting on my butt in the car for 
several hours tomorrow.  Perfect time to really think about this.
 
> Bingo. I just associate it with templating, because template engines
> -all- buffer as far as I can tell.
> 
> Even for non-realtime apps, it's important, because it's nice to give
> the browser something to munch on while the rest is generating. Users
> like feedback.

Sometimes.  If it only takes a bare fraction of a second to generate the 
whole response then it is no big deal.  On the other hand if you are waiting 
a half a minute while a very large report is generated, it'd sure be a lot 
nicer to stream that report out as it is built.

The thing with templating and buffering is that it's a much easier problem 
to solve if one is buffering the entire response.  

> Fifteen wouldn't be so bad even with the green threads.
> 
> Some of the fastest web servers out there use non-blocking IO 
> instead of threads (which is what Ruby threads do internally.)

Maybe.  I suppose it does depend on the hardware that one is running it on 
and on what is actually involved in generating the streams.  I posted some 
benchmarks in the other fastcgi/webrick thread, but on moderate hardware 
(PIII 800Mhz) I can handle mid 30s/second requests with 4+k or so of data 
returned per request out of one process (about 160-170k/second total 
transfer rate).  Larger requests reduce the number per second, but the 
throughput goes up.  25/second with a throughput of about 410k/second is the 
highest I've seen in tests so far.  Interestingly (to me, anyway), the 
concurrency doesn't matter much at all in the end results.

So, I suppose what I am saying is that if a person could stream a response 
out of Iowa (which is not something that could be implemented before, I'm 
guessing, Julyish), Ruby and Iowa probably would provide sufficient 
performance to stream at least some types of content to a couple handfuls of 
recipients at the same time.
 
> Then I realized that if mod_proxy could speak over a unix-domain 
> socket, I could just use WEBrick directly with a little hacking.
> 
> That made me realize that CGI variables is a poor, and webrick is a
> somewhat better abstraction of HTTP.

I'm with you there.  I just want an easy to understand abstraction that 
gives me access to all of the HTTP headers, both coming and going, and wraps 
all of it in some convenience.  It is at least half familiarity, but I do 
like the way an Apache::Request breaks up a request.


Kirk Haines