[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Standard APIs for databases, Web-apps

From: Toby Butzon
Subject: Re: [Chicken-users] Standard APIs for databases, Web-apps
Date: Fri, 10 Feb 2006 14:37:45 -0500
User-agent: Mutt/1.5.11

I don't mean to start a flamewar. With respect, Graham and everyone
else, I'm throwing this out there to see what you guys think.

On Fri, Feb 10, 2006 at 11:29:29AM -0500, Graham Fawcett wrote:
> Adding proper interfaces at these two points would serve multiple
> duties, including (a) easier porting of code from one backend
> (database or Web server) to another, and (b) the opportunity for
> "middleware" components (such as O/RM mappers on the database side,
> and mod_* style components on the Web side).

I find APIs designed around porting and middleware are too often
cumbersome or counterintuitive, while the benefits gained in porting and
installing "middleware" are minimal.

> Two popular database APIs in other languages come to mind: JDBC (Java)
> and DB-API (Python). Neither is a perfect fit for Scheme, though the
> simplicity of DB-API might make it a good source of ideas. I don't
> know whether a similar layer has been implemented in some other
> Scheme.

I don't know much about DB-API, but JDBC is dumb. Here's the gist, for
those who haven't used it:

You use JDBC's standard API to locate/instantiate the vendor-specific
(i.e., MSSQL, Oracle, etc.) driver. (The driver pretty much has to be on
the classpath for this, or in a similar system-standard place. You
generally *don't* point at the specific driver in your code, e.g.
"C:\drivers\oracle.jar"; instead, you say it's ""
or something like that. It's been a while, I'm just trying to give the
idea.) Then that object is essentially a factory for other objects,
etc., for querying the database and accessing the results.

The problem I have with all this is, unless you *really* focus on being
non-database-specific, and make try to force all the database
interaction into its own "box", you'll end up with SQL statements
throughout your application (along with the associated references to
the JDBC API). That's bad because SQL *isn't* non-database-specific
(even though that was the original intent), so you'll have to chase down
those points if you change databases anyway. 

The only way to maintain portability in this case is to make the database
code a well-organized, compact "layer" between the DB and the rest of your
app. Then if the DB changes, the layer is all that has to change. But
once you start thinking like this, the app-dependant "layer" takes the
place of JDBC's API. The API is at that point useless, and only confuses
matters because its notions don't always map well to the DB vendor's
notions of queries, responses, etc. It's clearer to use the DB vendor's
library/API directly, and forget JDBC even exists.

> On the Web front, I would love to see something like the WSGI proposal
> that is current in the Python community. WSGI is somewhat analagous to
> CGI (the interface, not the execution model): it's an in-process
> contract between server-communication code on on side (scgi, fcgi,
> tcp-server) and Web application code on the other. This decoupling
> allows the vast sea of Python Web frameworks to share common Web
> server bindings, and lets those frameworks share middleware components
> (authentication, logging, content-validation, etc.) as well as
> higher-level components from other frameworks.

Hrm... so the vast number of frameworks out there don't actually do
different jobs? They're copies of each other with maybe a few innovative
ideas each?

This is one complaint I hear about all the software out there on the
web. There's so much of it, and lots of it does the same thing, and in
many cases, there's no discernable quality difference.

Another point is: One thing I like about Spiffy is that you can control
just about any behavior you want. You don't need to go figure out how
some mod_* works (only to find out in some cases what you want isn't
supported). You're better off, IMHO, knowing how HTTP works, and being
able to do whatever crazy stuff you want to in the web server. There's
no good reason (other than there only being one port 80 on each server)
to not run each web app in its own web-server process, that can do
whatever funky, custom stuff it wants to do.

The mod_*s are the right idea, as far as conceptualizing things and
giving a standard way to do something, but in Spiffy that might as well
be just a separate .scm file that hooks in. You want mod_mysql_auth?
Just drop in the .scm file. No reason to have a sysadmin load a module
into Apache for you, when you control the entire web-serving process for
your application.

> I'm currently working on an SCGI adapter for Chicken; I'd like the
> "inside" of this adapter to speak a WSGI-like protocol. Ideally, I'd
> like to help rework Spiffy's internals, so that it could speak the
> common protocol, and decouple it from http-server at its dedicated
> back-end. I'd be happy to discuss implementation details with anyone
> who's interested.

I'm only confused about why you would do this in the first place. What
alternatives are there to spiffy? And if there are none, but "may" be in
the future, why would there be? Why not continue to improve spiffy?

What I'm hearing is that you want to refactor Spiffy. What I'm asking
is, why? It sounds like refactoring for the sake of it.

Again, I'm not trying to be personal, Graham. I'm just trying out ideas.

-- TB

reply via email to

[Prev in Thread] Current Thread [Next in Thread]