Hi all,
Sorry for making so many posts in the last couple of days. Basically, over the last couple of months since OSC’s release a few issues have come up to the API design and I wanted to take care of those things and see what people think.
There are three major changes to the API.
-
Synchronous functions throw
osc::Exception's which wrap theasio::error_codereturned from thebind,closeandshutdownmethods. -
Asynchronous functions now take as arguments error handlers and possible complete handlers. Functions such as
sendandlisten, which dispatch their work to the givenasio::io_servicetake functions as arguments. For instance, thesendfunction takes an optionalOnErrorFnwith the signaturevoid( asio::error_code )and another optionalOnCompleteFnwith the signaturevoid(). The errorFn would be called in the case of an error on the send and the completeFn would be called if there was no error. This basically replaces the global handlers and setters that is in the api now. -
Finally, and possibly the most controversial change, is the choice to separate the naming scheme between
osc::ReceiverUdpandosc::ReceiverTcpof the operation that begins reception at the OS level. Forosc::ReceiverUdp, the function’s name islisten. Forosc::ReceiverTcp, the function’s name isaccept. The differences were chosen to signal the underlying differences in what is actually happening. Withlistenon theosc::ReceiverUdpside, we’re indiscriminately reading and accepting messages. Withaccepton theosc::ReceiverTcpside, we’re binding a socket that’s accepting Tcp connections and then firing asynchronous read’s on the newly created sockets. Most of the reason for the change is not only clarity on the operation but also due to the fact that there are different arguments in each signature. Theosc::ReceiverUdp::listensignature accepts anOnErrorFn, with signaturebool( const asio::error_code &/*error*/, const protocol::endpoint &/*originator*/)that is used by the underlying read function. Theosc::ReceiverTcp::acceptsignature takes anOnAcceptErrorFn, which is called in the case of an acceptor error, and has the signaturebool( asio::error_code error ), andOnAcceptFn, which controls the caching of a newly created and connected socket and has the signaturebool( TcpSocketRef, uint64_t ). That was a mouthful. There was some discussion about whether this difference was needed. Some believed that it was more important to allow an ease of swap between the two different protocols as far asci::oscwas concerned but my belief is that, because these two protocols are so different that abstracting them would make it very hard to handle and control the underlying complexity.
Anyway, you can see examples and some comments detailing all of the API changes in the SimpleReceiver sample and SimpleSender sample. Definitely would love to hear what people think.
Best,
Ryan