Ben, > >By now it is clear that using 0MQ requires a mental paradigm shift (the > >"a-ha" moment) and -- unfortunately -- we are doing were little to > >alleviate it for the users. That's the reason IMO why "0MQ is > >interesting but lacks documentation" complaint is often heard -- even > >though there's detailed reference (man pages) available. > > Its more than a basic queue once you do cross machine pipes , pub/sub and > filters your building an Eventing (EDA) system and these are strictly in > geek land . It requires some time and effort ( consider what happens when > you chain subscriptions on different machines you start creating a network > graph etc) , the more you learn the more complex it gets ( but also how much > more capable the system becomes) . > > I once tried to introduce an eventing system in a large company and it was > so far beyond them it's not funny , they were still struggling with basic > push /pull , SOA and how to migrate of cobol yet alone how SOA services can > be event driven via a subscription . I ended up implementing it under the > cover of SOA and it worked very well , note however I put a WS-EVenting > wrapper on top which allows Visual Studio users to simply generate a proxy > to the machine create an easy subscription and start receiving data ( they > were a .NET shop on the client) , all devs understand pub /sub and they > started creating company wide data events for the organization to hook into > instead of resorting to DBs foreverything..
There are two problems here IMO. First one is changing how systems are implemented at the corporate scale. The momentum is so big here that we can be grateful for DBs being used at all by now instead of raw files :) There's no way to solve that. Just wait 30-40 years and the new technologies will get gradually adopted. The second problem is an experienced user who used messaging solutions before, knows the problem space etc. In this case the problem is that 0MQ fundamentally differs from other systems and initially (AFAIU) seems to be insufficient to perform the task required: "I cannot mix state notifications and control infrastructure within a single socket? What kind of lame messaging system is that?" Another manifestation of the problem is people trying to use PAIR sockets for everything, basically degrading 0MQ to a dumb TCP socket wrapper. It requires few a-ha moments to grasp the concepts. My original comment was about how to make this as painless as possible. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
