Hi Martin,
I'm not really sure what you mean by pros/cons in this context.
The SAP HANA driver is as native as it can get. It's JDBC 4.0 compatible and supports every way to interact with SAP HANA that is externally supported.
If you develop in JAVA it's certainly the most low-level, "close-to-the-machine" way there is.
Obviously you can also implement access e.g. via ODATA but that would add processing layers on both client and server side.
To develop a native 3rd party driver implementation would be at least pretty difficult. While the network protocol is at least roughly documented (see the SAP HANA reference documentation) there are certainly aspects of the protocol implementation that won't be documented internally.
So, here you are with a proprietary wire-protocol that you can only implement by using reverse-engineering - which violates the license agreements (and the law in come countries).
In my eyes this limits the options to implement an alternative driver (regardless of the API you want to implement it for).
I think more fruitful would be to ask about limitation of each driver and look into how these can be overcome. We (SAP) certainly have an interest in learning what actual requirements customers have.
For example: the current JDBC driver doesn't allow to set a LOB value via a StreamInterface. Instead the binary data has to be assigned via a byte array at once. This is a limitation that other JDBC drivers don't have and although this limitation would require functional enhancements on the SAP HANA server as well ( e.g. you need to have a concept of LOB locator and client side LOBs in order to deal with streaming data) if there is a use case that absolutely requires this feature, it would be very interesting to hear about that.
Anyway, maybe you explain a more in detail what exactly it is you're after...
- Lars
