|
Ok, so that's what I feared :) you want to re-implement a carob in
erlang The problem here is that the protocol is subject to changes... Actually, the whole point of Carob is to insulate applications from protocol issues. Keeping the protocol implementation private brings a great degree of freedom for developers, allowing them to easily implement new features, optimize performance and even sometimes fix bugs without disrupting backward compatibility. So, having a third implem (additionally to jdbc driver and carob) will lead to yet-another lib to maintain upon any protocol change. A better approach could be to make use of Carob via C++ erlang facility: <http://www.erlang.se/doc/doc-5.4/doc/tutorial/part_frame.html>You will then get the best of each: an erlang connector much easier to implement (thanks to carob API) + the benefit of Carob's updates, sticking to protocol changes, transparently What do you think ? This being said, Carob is open source, so if you decide to implement a native erlang connector, we will be pleased to provide you with the spec. If you want, you can already have a look at this class javadoc which contains all commands: http://sequoia.continuent.org/doc/latest/api/org/continuent/sequoia/common/protocol/Commands.html Thanks you, Gilles. Daniel Bartlett a écrit : Hi Gilles,Gilles Rayrat wrote: |
_______________________________________________ Carob mailing list [email protected] https://forge.continuent.org/mailman/listinfo/carob
