Subject | Re: [IB-Java] Re: JDBC Development |
---|---|
Author | Mark O'Donohue |
Post date | 2001-04-27T13:44:51Z |
Hi Alejandro
alberola@... wrote:
The internal access method, be it 3050 socket or jni should basically
hidden from the outside world.
Although you could write something that used a lower layer, (and in the
early days of development that may be all that is available) I don't
think it's wise, talking to firebird through the standard jdbc interface
is what I would recommend.
Or are you talking about writing a suite of programs that sit on top of
the jdbc layer?
In that spirit of doing just a type4 driver, i'd suggest ( but feel free
to ignore at will)
org.firebirdsql.jdbc.type4 - type 4 direct socket
implementation specific classes.
org.firebirdsql.jdbc.type2 - type 2 jni call implementation
specific classes.
org.firebirdsql.jdbc - interfaces, Driver, common
classes etc.
As it gets going there are likely to be subpackages of the current ones
for example:
org.firebirdsql.jdbc.type4.gds
org.firebirdsql.jdbc.util
Other packages that use the jdbc driver to talk to a firebird server,
would go in
org.firebird.<whatever> and subpackages as I see it, or have I missed
the point.
In terms of a module name for CVS i'd go with (as per earlier post)
something with "jdbc" in the name since you want people who go looking
for the jdbc driver to find it easy.
firebird-jdbc ?
Remember we can change it all later (even the cvs bits), for now its
probably best to work up a prototype, often it takes you to be half way
down the track and have road tested a few ideas before a realistic
choice on the correct packaging structure emerges.
Cheers
Mark
--
Your database needs YOU!
http://firebird.sourceforge.net
alberola@... wrote:
> Hello,I thought the idea was to write a type 4 jdbc driver?
>
> I agree with you. The FireClient is a too general name that
> could cover all the family of Firebird clients and is not
> suitable for this Java client.
>
> But this module won't be only a jdbc driver, it will be a
> complete suite of client APIs writen in Java. You will be
> able to write a Java application using GDS avoiding the
> use of JDBC in some contexts where you need functionality
> not found in a standard JDBC driver.
The internal access method, be it 3050 socket or jni should basically
hidden from the outside world.
Although you could write something that used a lower layer, (and in the
early days of development that may be all that is available) I don't
think it's wise, talking to firebird through the standard jdbc interface
is what I would recommend.
Or are you talking about writing a suite of programs that sit on top of
the jdbc layer?
In that spirit of doing just a type4 driver, i'd suggest ( but feel free
to ignore at will)
org.firebirdsql.jdbc.type4 - type 4 direct socket
implementation specific classes.
org.firebirdsql.jdbc.type2 - type 2 jni call implementation
specific classes.
org.firebirdsql.jdbc - interfaces, Driver, common
classes etc.
As it gets going there are likely to be subpackages of the current ones
for example:
org.firebirdsql.jdbc.type4.gds
org.firebirdsql.jdbc.util
Other packages that use the jdbc driver to talk to a firebird server,
would go in
org.firebird.<whatever> and subpackages as I see it, or have I missed
the point.
In terms of a module name for CVS i'd go with (as per earlier post)
something with "jdbc" in the name since you want people who go looking
for the jdbc driver to find it easy.
firebird-jdbc ?
Remember we can change it all later (even the cvs bits), for now its
probably best to work up a prototype, often it takes you to be half way
down the track and have road tested a few ideas before a realistic
choice on the correct packaging structure emerges.
Cheers
Mark
--
Your database needs YOU!
http://firebird.sourceforge.net