{"action":"created","issue":{"url":"https://api.github.com/repos/zeromq/netmq/issues/448","labels_url":"https://api.github.com/repos/zeromq/netmq/issues/448/labels{/name}","comments_url":"https://api.github.com/repos/zeromq/netmq/issues/448/comments","events_url":"https://api.github.com/repos/zeromq/netmq/issues/448/events","html_url":"https://github.com/zeromq/netmq/issues/448","id":128424492,"number":448,"title":"Feature Request: Do not obsolete/deprecate NetMQContext","user":{"login":"MikeFair","id":2304557,"avatar_url":"https://avatars.githubusercontent.com/u/2304557?v=3","gravatar_id":"","url":"https://api.github.com/users/MikeFair","html_url":"https://github.com/MikeFair","followers_url":"https://api.github.com/users/MikeFair/followers","following_url":"https://api.github.com/users/MikeFair/following{/other_user}","gists_url":"https://api.github.com/users/MikeFair/gists{/gist_id}","starred_url":"https://api.github.com/users/MikeFair/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MikeFair/subscriptions","organizations_url":"https://api.github.com/users/MikeFair/orgs","repos_url":"https://api.github.com/users/MikeFair/repos","events_url":"https://api.github.com/users/MikeFair/events{/privacy}","received_events_url":"https://api.github.com/users/MikeFair/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-01-24T20:55:12Z","updated_at":"2016-01-25T08:49:52Z","closed_at":null,"body":"I noticed that manually creating a NetMQContext is being marked as obsolete.  Instead, I propose extending the \"new Socket()\" constructor methods to take a provided context; e.g \"new Socket(m_context) (and perhaps even allow Contexts to be named and some static discovery and management functions to the NetMQContext class).\r\n\r\nI like the default simplicity of having a static unnamed context maintained at the library level for a simple Process; but I don't think creating contexts should be removed or marked obsolete.  If for no other reason than porting ZeroMQ code from other languages; but they also provide an extremely useful role for more complex infrastructures and services.   \r\n\r\nContexts create the equivalent of a network switch, VLAN, WiFI SSID, Autonomous System ID, or other organizational/security boundary to group communication areas within a single process.  It creates logical partitions to isolate independent communication scopes within the same process.\r\n\r\nFor example, using discovery protocols, I would expect every Socket within the same Context to be discoverable to every other Socket within that Context, but I wouldn't expect Sockets across Contexts to be automatically discoverable as part of the same peer Zone.  \r\n\r\nThe context creates a natural boundary in that sense; establishing isolated discovery zones. If I wanted to create multiple discovery zones within the same Process, manually managing the Context for each Zone is a simple pattern that's easy to understand and makes complete sense from a programming perspective.  One can first discover the \"Zones\" (aka Contexts; even give them a name) within a process, and then discover all the \"Queues\" (Sockets) that exist within those Zones.  \r\n\r\nI always pictured \"Context\" as being usable for something equivalent to \"domain name\"; the same process might be providing its service to multiple \"domains\" at the same time (like a Web, Video Conference Streaming, or FTP server). The Context is an easy boundary to configure, control, and isolate the collection of Sockets that belong to each separate domain.\r\n\r\nThe Context can expand to include the role of collecting, storing, managing, and aggregating information about all the Sockets it controls. And methods to request monitoring and inspection at the context level could provide event feeds on the creation/deletion of all Sockets (Queues) within that Context; a \"tap\" to tee off all of the messages happening on a particular Socket for debugging/inspecting a live running system; and perhaps even a way to manually manage the Sockets themselves (like if the State Machine for a Socket gets out of whack, this method could provide a way to discover the conditions and even allow us a way to manually \"fix\" the Socket without rebooting the process).\r\n\r\nUsing Unity as the rendering engine, this idea is one of the things I've been investigating.  Imagine processes hosted at an ISP for you.  The service processes themselves would likely each deal in many different user's domains (The File Server has code that specializes in Disk I/O while the Web Server specializes in rendering Web Pages; but the processes themselves are each handling multiple domains at the same time).  \r\n\r\nIf these services were created in separate Contexts within each OS Process; one for each Domain they participate in, then that Context object could provide all sorts of useful functions.  \r\n\r\nThe Unity application on your local laptop could inspect and manage all the services running for you around the globe because it could connect to the isolated context for your service within each process at the various locations.  Enabling Contexts to connect with each other across processes and then machines makes for an internet wide discovery zone for a single administrative domain.\r\n\r\nIf the Context gets removed, we lose that level of Socket collection, isolation, and management opportunity.\r\n\r\nThanks,\r\nMike\r\n"},"comment":{"url":"https://api.github.com/repos/zeromq/netmq/issues/comments/174439760","html_url":"https://github.com/zeromq/netmq/issues/448#issuecomment-174439760","issue_url":"https://api.github.com/repos/zeromq/netmq/issues/448","id":174439760,"user":{"login":"somdoron","id":2715638,"avatar_url":"https://avatars.githubusercontent.com/u/2715638?v=3","gravatar_id":"","url":"https://api.github.com/users/somdoron","html_url":"https://github.com/somdoron","followers_url":"https://api.github.com/users/somdoron/followers","following_url":"https://api.github.com/users/somdoron/following{/other_user}","gists_url":"https://api.github.com/users/somdoron/gists{/gist_id}","starred_url":"https://api.github.com/users/somdoron/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/somdoron/subscriptions","organizations_url":"https://api.github.com/users/somdoron/orgs","repos_url":"https://api.github.com/users/somdoron/repos","events_url":"https://api.github.com/users/somdoron/events{/privacy}","received_events_url":"https://api.github.com/users/somdoron/received_events","type":"User","site_admin":false},"created_at":"2016-01-25T08:49:52Z","updated_at":"2016-01-25T08:49:52Z","body":"@MikeFair I'm not sure about your catch of context, the context is just a background thread doing the IO of NetMQ. That all it is, also the zeromq community is going away from context, it is just adding unneeded complication. Think of it is operating system doing the IO, you don't know how many threads the OS allocating to manage IO, also you cannot say to the OS I want my IO to be isolated from other IO operations. I think the context is just confusing, when I'm explaining NetMQ to new users and I need to explain the context I just say \"it just something you have to create and pass around\", that is just wrong.\r\n\r\nRegarding managing, isolation, etc, nobody really needs that, if one day someone will come with real problem, we can solve that, but this is kind of might be a problem just complicated the library and add waste.\r\n\r\nNetMQ and ZeroMQ is hard libraries to learn and have some learning curve, I think removing the context reducing this learning curve, make the library smaller and less confusing.\r\n"}}