From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Date: Mon, 31 Jul 2000 09:09:20 +0000
From: nick@lurcher.org
Message-ID: <8m1mmf$9bg$1@nnrp1.deja.com>
References: <20000729122807.A382@tiger.home.net>
Subject: Re: [9fans] database fileservice
Topicbox-Message-UUID: eef53fa6-eac8-11e9-9e20-41e7f4b1d025

In article <20000729122807.A382@tiger.home.net>,
  9fans@cse.psu.edu wrote:
> Anthony Sorace wrote:
>
> > along the lines of what you're doing, i'd like to
> > see a service that can connect to arbitrary SQL
> > servers (either remote or local) and provide a
> > 9-ish interface to that, much like /net. that way
>
> Yeah, that *would* be nice, and probably we'd have the thing quicker
> that way (by just concentrating on the client side).
>
> I first looked at porting unixODBC and then building the fs service on
> top of that, but I didn't like how the unixODBC code looked, and
> couldn't get the will to port it.  Nothing against the code itself,
> it's probably just the nature of the thing: ODBC has gotten a lot
> more complicated than I remember, or I've gotten simpler. There were
> also some weird shared library loading things (for dynamic loading of
> drivers) and a lot of Windows-mimicking all around which I didn't want
> to wade into.
>
>  Steve Harris
>
>

Hi,

If you wanted any help with the port and didn't mind explaining plan 9
to me I wouldn't mind helping. I have been looking for a excuse to look
at plan 9. As to the complexity and windows-ness, I can't rearly argue,
the whole point of unixODBC is to duplicate what is available on windows
on non windows, not (as is tempting) to remove a lot of duplication of
things that is ODBC 3. AS to the dynamic loading, thats half the point
of the driver manager, you link the application to the DM and select the
driver at run time.

Nick Gorham


Sent via Deja.com http://www.deja.com/
Before you buy.