Hi,
there was a ugly problem with the implementation of this connect stuff.
The binary rpc protocol has a function name and a optional domain, which
is something like a namespace. This is done to be more similar to xmlrpc
or json over http, which both have a url and a function name.
The binary client now got this new "realConnect" flag to the connect
methods. Since the domain parameter is optional in the method were
already 2 connect variants - one without domain and one with domain, I
needed 2 separate methods to be compatible. So we had previously the methods
connect(const std::string& host, unsigned short port, const std::string&
domain = std::string());
After the change we got:
connect(const std::string& host, unsigned short port, bool
realConnect = false); // connect without domain
connect(const std::string& host, unsigned short port, const
std::string& domain, bool realConnect = false);// connect with domain
So we can do:
cxxtools::bin::RpcClient client;
client.connect("somehost", 7777);
or
client.connect("somehost", 7777, "domain");
And now something strange happened. The C++ compiler has 2 alternatives.
The 3rd parameter is either a bool (realConnect) or a const std::string&
(the domain). Both need a conversion since we pass a const char*. The
compiler decides to convert the const char* to bool! So instead of
setting the domain, the domain is empty and realConnect is set to true,
since the const char* is not 0.
I talked to a friend about that and we found a solution, which I know
implemented.
The realConnect parameter is gone again.
Instead we have a method prepareConnect(connectionparameters), which
passes the connection parameters to the client and a method connect()
without parameters, which really connects and possibly throws a exception.
Additionally to be API compatible, I implemented methods
connect(connectionparameters), which calls prepareConnect and connect().
The change to the user is now, that the connect methods, he have used,
now really connect and hence may throw a exception, when the connection
is not successful. So it does, what the user has previously expected.
The actual connect() method without parameters is optional, since the
rpc clients connect (or reconnects) to the remote host when not already
connected on every rpc call.
The same logic is implemented in the http client.
The user can also pass the connection parameters using the constructor.
The constructor calls just prepareConnect. It do not throw.
I pushed the changes already. Testing is welcome. The next step is to
add unittests for all connect methods.
Tommi
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Tntnet-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tntnet-general
