Re: Web APIs

On Fri, May 28, 2004 at 04:21:30AM +0900, Lothar Scholz wrote:
> Hello Aredridel,
> 
> A> I've been working with web programming for a while now, and I've yet to
> A> find a totally satisfactory API. I like using literate URLs, and no
> A> system so far supports that well.
> 
> Do we really need another one :-( ???

Well, we don't have many.  I don't want to write another Rails, another
IOWA, or another Borges, I'm more keen to polish up a really good API
that such would build on -- and probably re-implement the connection to
the webserver process (should there be one) instead of basing it on the
ugly, hard-to-use and semantically-ill-defined CGI spec.

> I'm sick about having 100 different solutions with each one having its
> highlights and drawbacks but none of them competitive to J2EE, Zope or
> even PHP. Okay ruby does not have native threads so there can't be
> anything competitive to J2EE, but maybe we can get something more
> stable - that would be a huge improvement.

Me too.  I've not used J2EE (though I'd love to hear a summary of what
it does well), but I've used PHP and looked at Zope a lot for ideas.
They're too high level for what I'm thinking, less of a platform to
build on than a platform to code for.

> And most important, it is time for the community to decide about 2 or
> 3 standard solutions and send the rest of all this 80% unusable frameworks
> to hell. To much competition is not a healthy situation.

Yes -- I'd love to see the best-of-the-breed polished up and made
useable, and let the rest go.

What I'd really like to see is, optimally, the WEBrick API extended to
be extremely and generally useful, and separate from the specifics of
its HTTPServer.

Part of the problem that a lot of systems have is that the web server
itself doesn't give enough information, or gives it in a hard-to-use
way. (the CGI variables REQUEST_URI, SCRIPT_NAME, SCRIPT_FILENAME, and
PATH_INFO come to mind).  It's hard to build an excellent application
when you have to keep writing a routine to guess the URL the user
entered to get to the request you're handling, and it's also hard to
write good applications when the framework ties your hands: When you
can't, for example, send a redirect to the browser (or if you can, you
can't choose between codes 301, 302 and 307) -- that's bad.

I'd love to see a framework that merges the best of WEBrick, FastCGI,
ISAPI modules and CGI (and I mean the protocol, not cgi.rb), and puts it
under a clean, simple umbrella that doesn't hide HTTP from you, just
abstracts it as it was meant to be.

I want the moon, don't I?

Ari