Subject | Re: [IB-Java] Re: JDBC Development |
---|---|
Author | Mark O'Donohue |
Post date | 2001-04-25T18:09:23Z |
Hi All
I sent the bottom attachment in a personal reply to Alejandro, he
directed me back here, since a lot of what I was talking about was being
discussed,
So I thought I'd put in my 10c worth. and redirect the mail.
I think cvs acces is up and going, so feel free to head off, don't worry
about making mistakes cvs is fairly forgiving, and we can fix most of
those :-).
alberola@... wrote:
probably what we should use, since that's how it's supposed to be, but
am happy to go with the flow.
[from the other private post I sent]
Hi Alejandro
I had a wonderful essay written but poof and mozilla died (I not so
enamoured of this latest version).
So here is the terse version [:-)]
I think we all think a type 4 driver is an excellent idea, I know from
posts/emails that David Jencks, Fred Toussi, myself and others think it
will work well.
One thought I had was to in your design to build a common front end that
uses a general interface to connect to the server process (say for
discussion here DBEngineConnectionInterface) one implementation allows
for a socket connection on port 3050 (DBSocketEngineConnection) which
talks natively to a remote FB/IB database.
It then allows for another implementation (DBJNIEngineConnection) that
uses direct jni C call to connect to the engine and databse on the same
machine without going through a socket layer.
Im not suggesting that you build it, but just to consider it in your
design so that there is an interface somewhere that allows this second
type to be built. I can see it being useful in high throughput
situations where you have a closely linked application server and
database. it also allows for an embedded install of java + Firebird DB
without having to have a Firebird server installed as well.
I was thinking of using a different subprotocol, as follows, but it
could be done other ways:
DriverManager.getConnection("jdbc:firebirdt4://server/dbname", user,
password);
DriverManager.getConnection("jdbc:firebirdt2://server/dbname", user,
password);
The type 2 driver could also directly connect to a database using
DriverManager.getConnection("jdbc:firebirdt2:dbname", user, password);
It would be nice to roll some of the existing type 3 driver into
DriverManager.getConnection("jdbc:firebirdt3://server/dbname", user,
password);
again by moving the existing interclient code into another
implementation of this connection interface.
BTW I think interclient is a dumb name and something like firebird-jdbc
or at least something with jdbc in it's name would be better.
Also with Jim having released his jdbc driver and it reportedly having a
"java like" flavour, I though this might be an interesting place to
start, even if it is in C++ it gives a good starting point for a type 2
driver and since it's a recently written C++ program, and follows a java
style it should give a good template for conversion into a type 4 driver.
Is everybody happy with ib-java/firebird-devel? I have been thinking of
creating a firebird-java and linking it with the egroups ib-java one,
just so there is a pointer and record of this stuff within the
sourceforge firebird infrastructure. But I suspect ib-java is good
enough for now. [MOD added: I now see Helen has been talking about this
too in the newsgroup]
When you have something to checkin send me an email, and we'll pick a
place for it (perhaps a new module called jdbc with subdirectories
type4, type3 (where we move all the current interclient stuff there)
type3server (interserver) and eventually a type2 subdirectory as well.
Any thoughts? [MOD added: I see this is pretty much in hand, Im happy
with whatever comes out]
Sorry for the essay, but a lot seems to have happened in the java/FB/IB
camp in the last week or so, and I thought I'd put in my 10c worth.
Cheers
Mark
--
Your database needs YOU!
http://firebird.sourceforge.net
I sent the bottom attachment in a personal reply to Alejandro, he
directed me back here, since a lot of what I was talking about was being
discussed,
So I thought I'd put in my 10c worth. and redirect the mail.
I think cvs acces is up and going, so feel free to head off, don't worry
about making mistakes cvs is fairly forgiving, and we can fix most of
those :-).
alberola@... wrote:
> I propose the following package names:I think that (if weve got firebirdsql.org) then org.firebirdsql is
>
> firebird.gds (Firebird API encapsulation)
> firebird.jdbc (JDBC implementation using GDS calls)
probably what we should use, since that's how it's supposed to be, but
am happy to go with the flow.
>I think it needs to have a "jdbc" in the module name, so it stands out.
> A name for our project could be FireClient (we need a name to
> open a module in Firebird CVS).
[from the other private post I sent]
Hi Alejandro
I had a wonderful essay written but poof and mozilla died (I not so
enamoured of this latest version).
So here is the terse version [:-)]
I think we all think a type 4 driver is an excellent idea, I know from
posts/emails that David Jencks, Fred Toussi, myself and others think it
will work well.
One thought I had was to in your design to build a common front end that
uses a general interface to connect to the server process (say for
discussion here DBEngineConnectionInterface) one implementation allows
for a socket connection on port 3050 (DBSocketEngineConnection) which
talks natively to a remote FB/IB database.
It then allows for another implementation (DBJNIEngineConnection) that
uses direct jni C call to connect to the engine and databse on the same
machine without going through a socket layer.
Im not suggesting that you build it, but just to consider it in your
design so that there is an interface somewhere that allows this second
type to be built. I can see it being useful in high throughput
situations where you have a closely linked application server and
database. it also allows for an embedded install of java + Firebird DB
without having to have a Firebird server installed as well.
I was thinking of using a different subprotocol, as follows, but it
could be done other ways:
DriverManager.getConnection("jdbc:firebirdt4://server/dbname", user,
password);
DriverManager.getConnection("jdbc:firebirdt2://server/dbname", user,
password);
The type 2 driver could also directly connect to a database using
DriverManager.getConnection("jdbc:firebirdt2:dbname", user, password);
It would be nice to roll some of the existing type 3 driver into
DriverManager.getConnection("jdbc:firebirdt3://server/dbname", user,
password);
again by moving the existing interclient code into another
implementation of this connection interface.
BTW I think interclient is a dumb name and something like firebird-jdbc
or at least something with jdbc in it's name would be better.
Also with Jim having released his jdbc driver and it reportedly having a
"java like" flavour, I though this might be an interesting place to
start, even if it is in C++ it gives a good starting point for a type 2
driver and since it's a recently written C++ program, and follows a java
style it should give a good template for conversion into a type 4 driver.
Is everybody happy with ib-java/firebird-devel? I have been thinking of
creating a firebird-java and linking it with the egroups ib-java one,
just so there is a pointer and record of this stuff within the
sourceforge firebird infrastructure. But I suspect ib-java is good
enough for now. [MOD added: I now see Helen has been talking about this
too in the newsgroup]
When you have something to checkin send me an email, and we'll pick a
place for it (perhaps a new module called jdbc with subdirectories
type4, type3 (where we move all the current interclient stuff there)
type3server (interserver) and eventually a type2 subdirectory as well.
Any thoughts? [MOD added: I see this is pretty much in hand, Im happy
with whatever comes out]
Sorry for the essay, but a lot seems to have happened in the java/FB/IB
camp in the last week or so, and I thought I'd put in my 10c worth.
Cheers
Mark
--
Your database needs YOU!
http://firebird.sourceforge.net