Hi,

I'm glad to hear you like the idea of a java to firebird core driver. I do
not wish to be overly pushy, but I think I suggested it in my post starting
this thread:
"One thing in particular that I am wondering about is if the interserver
part has any reason for existence. Why not write a JDBC driver in java
that talks directly to Firebird core? I think this would involve
translating the C client into java. I haven't however figured out just
which files this c client consists of."

Since it is just possible I may have time to pursue this project, I would
appreciate some hints as to if and where the XDR protocol definition is and
which files are involved. (I've figured out what most of interclient/server
does, but firebird is a somewhat larger project...)

Although perhaps I should not have put two questions into one post, I'm
also curious about any responses to my original second question:

On a separate thread, I am a bit confused by interclients insistence in the
database metadata that catalog and schema have no meaning in firebird. I
would think that catalog is more or less database, schema is more or less
owner. If you use datasources, catalog could be the JNDI- registered name
for a database rather than the file name. Any comments?

On 2001.02.23 10:01:34 -0500 Jim Starkey wrote:
> At 11:32 PM 2/23/01 +1100, Mark O'Donohue wrote:
> >
> >> Doing an interface that talks directly to 3050 is certainly
> >> feasible and probably not very difficult. The protocol is
> >> currently defined in terms of XDR, but could/should have a
> >> restatement as a straightforward line protocol. The more
> >> difficult and expensive (in performance) is the mapping from
> >> jdbc semantics to Firebird semantics. Maybe a careful study
> >> would reveal that it's not too bad, maybe even preferred.
> >
> >That's encouraging to hear, and would be interesting to have a look at
> >what the mappings would involve. But I suspect it's a bit of a pipe
> >dream at the moment and think that interclient or in your case a proxy
> >providing a type 3 solution is going to be our solution for a quite a
> while.
> >
>
> I've given this a little more thought. It's the way to go.
> It's more that feasible, it probably isn't difficult. Solves
> all sorts of portability and double copying problems. A
> sufficiently good idea that I may steal it for Netfrastructure
> (unlike Firebird, the Netfrastructure remote access is nowhere
> near the critical path, so the protocol is simpler; also, I
> gotten smarter).
>
> Clever boy, Mark.
>
> More on the rest of your post later.
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>