On Sun, Aug 11, 2013 at 6:46 AM, Edward Diener
OK, but you still need an explanation of how the end-user should use your named pipe functionality to do asio with each member function in your class where asio is possible. Using asio with named pipes in Windows involves making a connection, accepting a connection, sending data, and receiving data. In other words using asio with named pipes means never waiting on anything, but checking periodically if some operation has completed and doing other things if it has not.
I'll keep that in mind. For now I'm going to completely punt on asio behavior. Glad to give it, but you don't have much code yet on which to comment.
I was speaking more in the abstract. I'll be sure to let you know when I've actually got an attempt at the Windows implementation.
I would suggest you keep things really, really simple in your main interface. There should be the creation of a named pipe, listening for and accepting a connection, making a connection, reading data, and writing data.
I think you should also consider your named pipe being outside of Boost.ASIO rather than as part of it, mainly because named pipes can be synchronous if the user wants to wait, let's say in some background thread, for operations to complete.
This is an excellent point. I think I was getting a little focused on Asio
because it seems like a good idea, but I really know next to nothing about
it so there's no point in trying to implement it in the first pass.
On Sun, Aug 11, 2013 at 6:55 AM, Edward Diener
I heartily agree with this last comment. KISS. There's no need for two different classes. A single named pipe class should be able to handle creation of a named pipe, listening for and accepting a connection, making a connection, reading data, and writing data. It really is that simple at the basic level.
Fair enough. Since both you and Rob seem to be clear on that I'll pursue that approach. -- Geoff Nothing is ever easy.