> >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.. Ben _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
