KAMI,

> Currently there are complete UNO language bindings for:

> * C
> * C++ (compiler dependent, please see http://porting.openoffice.org
> for a list of supported platforms)
> * Java
> * Python

Probably I was not precise enough... As I understand, you post it here since
you plan to implement it in Java. Right?

> Built in support for database. You doesn't need external module.
> The SDBC Driver allows to use the database from OpenOffice.org
> without any wrapper layer such as odbc or jdbc.

What's wrong with such wrapper layer?

Does SDBC component becomes a part of the OpenOffice.org suite? If not, does
it need less configuration than JDBC? How is SDBC component installed?

I suspect that SDBC component in C++ would not require JRE to be installed.
But if the implementation language is Java, what's the difference?

> I don't know anything about new features. But I don't have knowedge
> about component modells. But from Frank Schönheit:
> "
> Additionally, SDBC (more precise: its extensions SDBCX and SDB) provide
> additional features which are not present in JDBC, or were not
> present at the time SDBC was invented.
> "

Let me explain why I ask this. Firebird has some internal limitations (like
absence of autoincrement field, absence of scrollable and updatable cursors,
etc.). Because of this, JayBird does not provide full JDBC implementation,
some parts are missing (like getting the auto-generated PK on INSERT,
updatable cursors). If additional features declared in SDBC are going to
provide access to the functionality that is not present in Firebird anyway,
I doubt that implementing SDBC component in Java brings any advantage
compared to JDBC.

When JayBird was started, we had already a JDBC driver called InterClient.
That was a type 3 JDBC driver that required a server-side component to be
installed on the same host with server. In addition to the configuration
burden, there were some other issues associated with it - multithreading
performance, etc. Creating a pure Java implementation of wire protocol
brought an advantage of having a lightweight type 4 JDBC driver that does
not have issues present in InterClient (though we have lost in some other
places, for example, "wire" protocol of InterClient was better optimized for
JDBC calls compared to native Firebird wire protocol - performance of
InterClient in some cases was better). Same happened with type 2 JDBC driver
(driver that accesses Firebird through JNI layer) - we gained ~30% when
connecting to a server running on the same machine via IPC and we have a
possibility to use an embedded Firebird.

Similarly, if you want to implement SDBC "driver" for Firebird, I would try
to answer first the question "What does it bring?". An answer "Because it
would be native OpenOffice.org component" is not good enough for me (though
I do not mind if it satisfies you :) ).

> Please contact with Frank (Frank.Schoenheit*nospam*Sun.COM)
> *nospam* means @
>
> or you may write to users@... (project's users
> mailing list)

If you're going to implement SDBC, you have to do this :)

Roman