From: Aredridel <aredridel@...>
Date: 2004-05-28T12:58:39+09:00
Subject: Re: Web APIs

> > 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.  

Yeah. Just a toy example, so don't break your brain.

> > > 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.

That's always the clincher, eh?

> > 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.

Yeah. I was thinking that other HTTP methods might be best. 

LISTAPPS /foo/bar HTTP/1.1

> > 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.

Yeah. In my case, try -several- minutes at the moment.

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

Yeah, exactly.  I'd like to see one that didn't, now that we've seen the
easy implementations.

> > 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.

Makes sense.

> 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.

Mmm.

> > 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.

Apache::Request isn't bad, nor is WEBrick::HTTPRequest and Response.

It's one part of the puzzle.

Ari