Difference between revisions of "Talk:OpenDBX/C API/Usage"
(New page: I think this is a great project. Congratulations to Norbert Sendetzky and the rest of the team for putting out something like this. A few years ago, I had wanted to develop a C/C++ libra...) |
m (Talk:OpenDBX/Usage/C API moved to Talk:OpenDBX/C API/Usage) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 12: | Line 12: | ||
- GUI tools for managing the driver registry and the datasource registries. | - GUI tools for managing the driver registry and the datasource registries. | ||
| + | |||
| + | |||
| + | '''Answer:''' | ||
| + | |||
| + | - A driver registry like you suggested is almost impossible to implement because drivers do not only depend on the used database but also on the platform (Mac, Unix, Windows, etc), the architecture (x86, x86-64, sparc, etc) and the installed versions of base libraries like the Linux/Unix libc. The alternative would be to implement an OpenDBX client which talks to a OpenDBX server using its own protocol. The server translates the requests into local calls to the OpenDBX library. That would be much work to do. | ||
| + | |||
| + | - An easy way to implement a network-wide datasource registry could be a web application providing the backend, host, port and database parameter strings (username and password must still be local for security reasons) via a HTTP response. The application could then use the provided parameter as input to odbx_init() and odbx_bind(). Fetching the parameter from the server could be done in a supporting library which don't have to be OpenDBX or even database specific, but I think it shouldn't be part of the core OpenDBX library. | ||
| + | |||
| + | - The GUI in the suggestion above would be a web interface. | ||
| + | |||
| + | --[[User:Nose|Nose]] 13:10, 1 May 2008 (CEST) | ||
Latest revision as of 09:07, 4 March 2009
I think this is a great project. Congratulations to Norbert Sendetzky and the rest of the team for putting out something like this.
A few years ago, I had wanted to develop a C/C++ library similar to OpenDBX but I unfortunately never got around to it.
Would it be possible to have these features as well:
- Driver registry: When a new database software (Postgres, Oracle etc) is installed. It can update the registry with this information. To update to a new version of the database, one needs only to upload the Driver binary and update the driver registry.
- Datasource registry: This would be similar to the ODBC datasource concept. By datasource, I mean a pointer to a database connection for any of the databases whose drivers are stored in the driver registry. So applications can connect to a database by searching for the datasource with a pre-configured name in the Datasource registry. It would also be great if it is possible to have a network-wide datasource registry such that OpenDBX applications can query for a named datasource and connect to it.
The Datasource registry makes it possible to have GtkWidgets etc which are 'data-enabled' to connect to a name datasource and then link to a field within a table in that datasource.
- GUI tools for managing the driver registry and the datasource registries.
Answer:
- A driver registry like you suggested is almost impossible to implement because drivers do not only depend on the used database but also on the platform (Mac, Unix, Windows, etc), the architecture (x86, x86-64, sparc, etc) and the installed versions of base libraries like the Linux/Unix libc. The alternative would be to implement an OpenDBX client which talks to a OpenDBX server using its own protocol. The server translates the requests into local calls to the OpenDBX library. That would be much work to do.
- An easy way to implement a network-wide datasource registry could be a web application providing the backend, host, port and database parameter strings (username and password must still be local for security reasons) via a HTTP response. The application could then use the provided parameter as input to odbx_init() and odbx_bind(). Fetching the parameter from the server could be done in a supporting library which don't have to be OpenDBX or even database specific, but I think it shouldn't be part of the core OpenDBX library.
- The GUI in the suggestion above would be a web interface.
--Nose 13:10, 1 May 2008 (CEST)
