Remove Sockets dependency/namespace insertion

[joelfrederico]

I think ZMQ is sufficiently different enough from Sockets that we should keep ZMQ functions in a separate namespace. Thoughts?

[stevengj]

This seems reasonable to me; it is an artifact of the days when send and recv were in Base. Tests are failing, though.

[vtjnash]

I expect Sockets will remain part of the base image for the foreseeable future, so there's no particular advantage to avoiding it.

[joelfrederico]

@stevengj Ah right! I should deprecate the methods on Sockets instead of removing them.

@vtjnash Wait... I'm confused, Sockets aren't currently part of base (Julia 1.0.2), what do you mean? Also, the reason (IMHO) for keeping them separate is that they have separate paradigms. The API's (the function interfaces) aren't identical, and the functionality is significantly different.

[vtjnash]

It's not part of the exports of Base anymore, since it now has its own top-level namespace, but it's still part of the base image.

Also, the reason (IMHO) for keeping them separate is that they have separate paradigms. The API's (the function interfaces) aren't identical, and the functionality is significantly different.

It's separate from TCP / UDP / domain-sockets perhaps, but I'm not sure the basic paradigm ("move these bytes from the sender(s) to receiver(s)") is much different. Perhaps you could explain more about what promises that Sockets makes that is significantly different from what is provided here by ZMQ? For example, we can observe that Sockets.recv is providing approximately the posix sendto function, while ZMQ more nearly provides the send function (without explicit sender). This merging of names however is common in Julia, since method overloading allows us to merge concepts that are same despite implementation considerations in C forcing them into separate functions.

[joelfrederico]

I believe the concepts are different even though the function names are the same. If you write a general library that uses the Sockets API and then extend that API as ZMQ.jl does, the ZMQ.jl sockets will not work properly. Here's why: The Sockets API and ZMQ API have different runtime contracts. Because the JIT-time API's are similar, it will be the runtime conditions part of the contracts that will be a problem. The general library will not function as intended, resulting in exceptions (if ZMQ.jl handles ZeroMQ error codes properly) and/or unintended behavior and possibly hanging. That will be a consequence of violating the ZMQ contracts while assuming the Sockets contracts. I believe it will not be possible to change the ZMQ behavior to meet the Sockets contracts without significantly modifying the bindings, which would defeat the purpose of ZMQ.

I am beginning to think you will only see this point if I provide an example, because at this point I haven't said anything new. I will attempt to provide you an example, although that may take some time. I will need to write a proof-of-concept library that uses the Sockets API successfully with TCP/UDP sockets but fails with ZMQ.jl sockets. I think if I can do that and make it compelling, you may agree with me that ZMQ sockets should not extend the Sockets API, even though superficially their API's may look similar.

[JamesWrigley]

I read through this PR and the linked issue, and my view is that there's not really much benefit in using a different API. People don't seem to regularly get confused by ZMQ.jl's implementation vs the implementations for TCPSocket/UDPSocket. Also at this point Sockets has been part of the API for long enough that it would be quite breaking to remove it, especially for so little technical reason, so I'm going to close this.