On 28 Jul 2013, at 17:20, Pierce Ng <pie...@samadhiweb.com> wrote: > On Sun, Jul 28, 2013 at 01:12:41PM +0200, Sven Van Caekenberghe wrote: >> Since UDP sockets are currently also in the same class, I don't see a >> need for a separate class in the current design. > > Hi Sven. Agreed, as I wrote in the other mail about gaining experience with > IPv6 as well.
OK >> Yes, the code is too cryptic/technical, a helper method or two would >> solve this. > > Done as per my newest blog post. Will add that when I create the issue. Yes, I've seen it. Good, that is what I meant. >>> Also, I'll be looking into the minor changes needed to support >>> SocketStream as well. >> >> Can you elaborate on that ? > > SocketStream has instance creation methods such as > openConnectionToHost:port:. To use Unix domain sockets, I imagine something > like openConnectionToIPCSocketPath:. Ah, OK, I understand. But there is SocketStream class>>#on: once you have your socket. That should be enough for testing client and server side. Once you validated it works, you could indeed add the #openConnectionToIPCSocketPath: convenience method. >> To add this, I would like some minimal tests as well (to be skipped on >> windows). > > I took a peek at SocketTest; the setUp method sets up a server socket, and > tests are run against this socket. This kinda like requires what is being > tested to be working in the first place? I understand your point, it is possible to have interesting theoretical discussions about unit tests, but a test that exercises the code is much better than none at all. If you don't like the setup of SocketTest, write your own test class, like DomainSocketTest. Tests are really important: they are live, validated documentation. Regarding the last blog post, does that mean that a VM change is now necessary or not ? Thanks for contributing ! Sven > Cheers. > > -- > Pierce Ng > http://samadhiweb.com/blog/
