[9fans] database fileservice

[9fans] database fileservice

[Steve Harris]

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

Re: [9fans] database fileservice

[nick]

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.

Re: [9fans] database fileservice

[Nick Gorham]

Stephen Harris wrote:

> Unfortunately I'm something of a beginner myself with Plan 9.
> It would probably be a good project to learn Plan 9 with, given that
> you are already familiar with ODBC.  I haven't touched ODBC in years,
> and it looked like for me it would be a learning experience for recent
> ODBC more so than for Plan9.  I'm going to try to port a database
> (postgres) instead because I've been interested in its internals anyway,
> and I think it would be nice to have a standalone database for Plan 9.

Ok, I have a box that I was going to rebuild, I will try and install plan 9
on it and see what happens.

> Yep, this *may be* a real problem though, since as far as I know
> there's no way to load shared libraries in Plan 9, it just hasn't
> needed it so far (which says a lot). You could rewrite a little to
> eliminate the dynamic loading, and instead just compile in the drivers
> you want, but as you say that would defeat the purpose of the driver
> manager.  Creative solutions to this would probably be welcomed by all.

Well there may be a more appropiate method, perhaps opening them as a
device of some such method, I must read more of the white papers first.

> Everything you do from now on will be more fun - Windows 95 installation

<grin>

--
Nick Gorham
"I wish there was a knob on the TV to turn up the intelligence,
There's a knob called brightness, but it doesn't work."
- Eugene P. Gallagher

Re: [9fans] database fileservice

[Stephen Harris]

Nick Gorham wrote:

> If you wanted any help with the port and didn't mind explaining plan 9 
> to me I wouldn't mind helping. 

Unfortunately I'm something of a beginner myself with Plan 9.  
It would probably be a good project to learn Plan 9 with, given that 
you are already familiar with ODBC.  I haven't touched ODBC in years, 
and it looked like for me it would be a learning experience for recent 
ODBC more so than for Plan9.  I'm going to try to port a database 
(postgres) instead because I've been interested in its internals anyway, 
and I think it would be nice to have a standalone database for Plan 9.

That being said, if you want to go for it I will try to help as much
as possible. Query result sets map naturally into a file heirarchy, so 
it will be a really nice thing when either port is completed, and we 
can write a database file service.

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

Yep, this *may be* a real problem though, since as far as I know 
there's no way to load shared libraries in Plan 9, it just hasn't 
needed it so far (which says a lot). You could rewrite a little to 
eliminate the dynamic loading, and instead just compile in the drivers 
you want, but as you say that would defeat the purpose of the driver 
manager.  Creative solutions to this would probably be welcomed by all.

Cheers,
Steve

Everything you do from now on will be more fun - Windows 95 installation