4 ms·

It's more of a passionate side project at the moment, as I am still reverse engineering the protocols involved. It's not close to completion, but I'm hoping to

It's more of a passionate side project at the moment, as I am still reverse engineering the protocols involved. It's not close to completion, but I'm hoping to have it done sometime in the next few months. It's not a high priority, as there are other ways to connect to Oracle. My goal is to get rid of all the non-Go dependencies, which would (for the first time, ever) finally make it a reality to have a single, small binary that can connect to "every" database and that can be freely distributed. If you'd like to help, please feel free to start an implementation. While I'm not following a specific development routine for the native Oracle driver, I do have a repository with a bunch of (non-building) code that I made to assist with inspecting the raw protocol captures.

grumpydba 8y ago
Someone has already been there, the protocol is very.. rich, I would say: https://blog.pythian.com/repost-oracle-protocol/ https://blog.pythian.com/repost-oracle-protocol/
tracker1 8y ago
Hell, if that lead to Oracle drivers for other languages, that could be amazing too. It's nearly incomprehensible to me why Oracle hasn't documented their protocol.
- emmelaich 8y ago
  Then it would difficult to change. For instance to support clusters and failover.
  - grumpydba 8y ago
    MSSQL server protocol is documented and failover is handled. Protocol are usually versioned, or the initial handshake allows client/server capabilities negociation. Oracle has copyrighted a poem that the clients needs to send to make sure reverse engineered drivers are not possible: https://noss.github.io/2009/04/28/reverse-engineering-oracle-protocol.html https://noss.github.io/2009/04/28/reverse-engineering-oracle... Business as usual for Oracle and their horrible ethics...