[web2py] Re: ZeroMQ in web2py
Derek, I was throwing off examples, but you have to remember, ZeroMQ is NOT just a replacement for a socket - it is a messaging library - a full-fledged, cross-platform, cross-language, high-performance, flexible scalable concise, messaging-tool-box, and it's NOT just for networking, but also for ipc and in-proc communication - there are limitless topologies that can build with it using modular-components - if you can't understand the benefits of that, I suggest you learn some more about it and what it can do, it's use-cases, etc. Here is a short example of why it is wrong to say that you would write less code without it: http://www.youtube.com/watch?v=wLLHv5GbZiQ It is also a case against using Tornado as a websocket/async server, and use gevent instead - the main case for gevent here, is that you don't have to start writing in a callback-fashion, which is horribly unreadable and difficult to maintain - and when you add-in ZeroMQ into the mix, then (on-top of the performance and capabilities you get in terms of topologie) you can actually have your entire code running in a single process and a single thread, while still being fast and non-blocking, and while entirely evading all of python's threading-issues... Here is a use-case for ZeroMQ, as a transport/connection-pool/load-balancing mechanism within a front-end web-server: http://www.slideshare.net/hungryblank/mongrel2-rugb The main benefit in this case, is that you could connect to multiple back-end servers simultaneously, all written in different languages, using different VMs and/or processes, and even running on different machines, and enable them to talk to each other. The potentials for ineroperabilirty are essentially limitless... -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[web2py] Re: ZeroMQ in web2py
And that's fine, but I still don't see the need for ZeroMQ in that example. It's not adding websocket support to a non-real-time web-app. It's only serving as the transport for messages from the webserver to the websocket server. You could accomplish that just fine with a regular TCP connection, which would require less code on the webserver and websocket server. They describe a pub/sub architecture, which is feasable using any of the websocket libraries, in fact, web2py comes with comet support already, so... again, there's not much of a need for ZeroMQ. That's fine if you want to implement something and submit it in contrib. It seems useful for the 'backend' parts to communicate with each other. http://greg.thehellings.com/2011/04/web2py-websockets-and-socket-io-part-i-basic-display/ On Saturday, April 13, 2013 4:05:45 AM UTC-7, Arnon Marcus wrote: Here is an example for an architecture of using ZeroMQ for adding WebSocket support to a non-real-time web-app, without much change to the existing code (server is PHP in this case, but the architectural structure is what's interesting) http://socketo.me/docs/push And here is a more in-depth and interesting example using python with gevent: http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets-and-flot-ftw.html -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[web2py] Re: ZeroMQ in web2py
Here is an example for an architecture of using ZeroMQ for adding WebSocket support to a non-real-time web-app, without much change to the existing code (server is PHP in this case, but the architectural structure is what's interesting) http://socketo.me/docs/push And here is a more in-depth and interesting example using python with gevent: http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets-and-flot-ftw.html -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[web2py] Re: ZeroMQ in web2py
I have no idea what you are trying to say there. I am saying that there is an explosion of solutions for every conceivable challenge, and the problem is that they are all islands-onto-themselves - there is no standard way for application to communicate with each other, and ZeoMQ could solve that. For example, let's take the central-logging use-case, let's say you've chosen Logstash - you have a server that collects log-information from many different other applications - there are too many varied ways in which that can happen, and every other application has a different one. Mostly, that is solved by either a centralized message-broker (say, RabbitMQ), or using Redis. Another example - a CI story (Continuous-Integration) : You have a process for automatically running your unit-tests, and in case any of them fail, it should generating an issue and submitting it so some issue-tracker (lets say Redmine). If all succeeds, it should commit the changes using a version-control (let's say Git), and push it to somewhere. Additionally, it may also create a task for code-review, in some ALM (Application-Life-cycle-Management) system, let's say Microsoft TFS for visual-studio (Team-Foundation-Server), or MyLyn for Eclipse. How many different applications have to talk to each other in this story? That's the overall background. As for web2py: It already has a ticketing system built-in, but I can't use it to talk to the rest of my existing CI story. I want something that can talk to Mylyn, as I have Eclipse, so I use Redmine, as I don't want to write a Mylyn connector in Java - that's not my field... So now I need web2py to talk to Redmine... I also want my web2py-app's application-level custom logging mechanism, to not only be saved to it's database, but also submit to Logstash. I may be able to do that with Redis, but it would be great if I didn't have to... Anyway, yes, it's cool, you don't worry about message delivery because it's completely out of your control. That's the exact problem with it though, message delivery is out of your control. You have no idea if a message is delivered or not. You can 'queue' tons of messages, and ZeroMQ won't tell you that those messages didn't get delivered. It's cool, but it's not a silver bullet. Contrib may be a place for it though. That is one of the common misconceptions. On the contrary - it is exactly thanks to ZeroMQ, that you have much MORE control over what is going on in your messaging architecture, NOT LESS. In sharp contrast to, say, RabbitMQ for AMQP, you are not locked into an implementation, or a strict protocol-spec - it is completely customizable. RabbitMQ simply implements the AMQP protocol-spec, so it MUST notify the senders about recipient's received message - it's a mandatory requirement in the QoS policy of the protocol. ZeroMQ CAN also do this, it is just NOT MANDATORY. The ability to submit to a recipient without it even being active, is a FEATURE, NOT a PROBLEM. It just means that a sending server may be set to have it's out-going sockets queued, so whenever the target-recipient comes on-line, he starts receiving the messages in the out-going queue. When that happens, there is nothing preventing from the recipient from sending back replies for assuring the message was received - in fact, by default most typologies are set so that every message-received, is echoed back to the sender, so it can cross-reference and make sure that the message goth through. Remember, both AMQP AND ZeroMQ are already being used in banks for transferring transactions, so the QoS is very reliable, if that is what you want - you just don't HAVE to use it, if you don't want to. -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[web2py] Re: ZeroMQ in web2py
Sounds to me like you have a couple of real life situations you need solutions for. So the best thing to do is start coding. If you're unsure about how to tackle the web2py integration, I'm sure people will provide comments once you present your specific ideas or code drafts. If you start out in a form of a plugin, keeping in mind that it could be integrated in web2py one day, you IMHO can't go wrong. Regards, Ales On Thursday, April 11, 2013 11:58:24 AM UTC+2, Arnon Marcus wrote: I have no idea what you are trying to say there. I am saying that there is an explosion of solutions for every conceivable challenge, and the problem is that they are all islands-onto-themselves - there is no standard way for application to communicate with each other, and ZeoMQ could solve that. For example, let's take the central-logging use-case, let's say you've chosen Logstash - you have a server that collects log-information from many different other applications - there are too many varied ways in which that can happen, and every other application has a different one. Mostly, that is solved by either a centralized message-broker (say, RabbitMQ), or using Redis. Another example - a CI story (Continuous-Integration) : You have a process for automatically running your unit-tests, and in case any of them fail, it should generating an issue and submitting it so some issue-tracker (lets say Redmine). If all succeeds, it should commit the changes using a version-control (let's say Git), and push it to somewhere. Additionally, it may also create a task for code-review, in some ALM (Application-Life-cycle-Management) system, let's say Microsoft TFS for visual-studio (Team-Foundation-Server), or MyLyn for Eclipse. How many different applications have to talk to each other in this story? That's the overall background. As for web2py: It already has a ticketing system built-in, but I can't use it to talk to the rest of my existing CI story. I want something that can talk to Mylyn, as I have Eclipse, so I use Redmine, as I don't want to write a Mylyn connector in Java - that's not my field... So now I need web2py to talk to Redmine... I also want my web2py-app's application-level custom logging mechanism, to not only be saved to it's database, but also submit to Logstash. I may be able to do that with Redis, but it would be great if I didn't have to... Anyway, yes, it's cool, you don't worry about message delivery because it's completely out of your control. That's the exact problem with it though, message delivery is out of your control. You have no idea if a message is delivered or not. You can 'queue' tons of messages, and ZeroMQ won't tell you that those messages didn't get delivered. It's cool, but it's not a silver bullet. Contrib may be a place for it though. That is one of the common misconceptions. On the contrary - it is exactly thanks to ZeroMQ, that you have much MORE control over what is going on in your messaging architecture, NOT LESS. In sharp contrast to, say, RabbitMQ for AMQP, you are not locked into an implementation, or a strict protocol-spec - it is completely customizable. RabbitMQ simply implements the AMQP protocol-spec, so it MUST notify the senders about recipient's received message - it's a mandatory requirement in the QoS policy of the protocol. ZeroMQ CAN also do this, it is just NOT MANDATORY. The ability to submit to a recipient without it even being active, is a FEATURE, NOT a PROBLEM. It just means that a sending server may be set to have it's out-going sockets queued, so whenever the target-recipient comes on-line, he starts receiving the messages in the out-going queue. When that happens, there is nothing preventing from the recipient from sending back replies for assuring the message was received - in fact, by default most typologies are set so that every message-received, is echoed back to the sender, so it can cross-reference and make sure that the message goth through. Remember, both AMQP AND ZeroMQ are already being used in banks for transferring transactions, so the QoS is very reliable, if that is what you want - you just don't HAVE to use it, if you don't want to. -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[web2py] Re: ZeroMQ in web2py
I thought about it, but I would have hopes someone with some experience with web2py internals and perhapse with zmq would rise to the challange... I wouldn't know even where to beging doing something like this myself.. -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[web2py] Re: ZeroMQ in web2py
TCP is only the transport - you still have your application-specific protocols that you'd need to write. If your logstash gets a message like 'addlog i like pizza 07-11-2011' it doesn't know whether 'i like pizza' is an application, a status, or a priority level. So ZeroMQ isn't going to make connecting differing things easier. You still need your application layer messages. For all Logstash would know, 07-11-2011 could be July 11th, or November 7th. If you have a 'version control' ZeroMQ socket, who's to say it's going to use Git? What about Mercurial? Svn? All of those speak different languages, so you won't make anything easier by using ZeroMQ. In fact, you'd make it more difficult since not all those systems would have a ZeroMQ endpoint. Sure, if they had them, then good, but you'd still need to have your application level protocol, and good luck getting all the source control vendors to agree on a single protocol. Also, fwiw I use fossil http://fossil-scm.org. On Thursday, April 11, 2013 2:58:24 AM UTC-7, Arnon Marcus wrote: I have no idea what you are trying to say there. I am saying that there is an explosion of solutions for every conceivable challenge, and the problem is that they are all islands-onto-themselves - there is no standard way for application to communicate with each other, and ZeoMQ could solve that. For example, let's take the central-logging use-case, let's say you've chosen Logstash - you have a server that collects log-information from many different other applications - there are too many varied ways in which that can happen, and every other application has a different one. Mostly, that is solved by either a centralized message-broker (say, RabbitMQ), or using Redis. Another example - a CI story (Continuous-Integration) : You have a process for automatically running your unit-tests, and in case any of them fail, it should generating an issue and submitting it so some issue-tracker (lets say Redmine). If all succeeds, it should commit the changes using a version-control (let's say Git), and push it to somewhere. Additionally, it may also create a task for code-review, in some ALM (Application-Life-cycle-Management) system, let's say Microsoft TFS for visual-studio (Team-Foundation-Server), or MyLyn for Eclipse. How many different applications have to talk to each other in this story? That's the overall background. As for web2py: It already has a ticketing system built-in, but I can't use it to talk to the rest of my existing CI story. I want something that can talk to Mylyn, as I have Eclipse, so I use Redmine, as I don't want to write a Mylyn connector in Java - that's not my field... So now I need web2py to talk to Redmine... I also want my web2py-app's application-level custom logging mechanism, to not only be saved to it's database, but also submit to Logstash. I may be able to do that with Redis, but it would be great if I didn't have to... Anyway, yes, it's cool, you don't worry about message delivery because it's completely out of your control. That's the exact problem with it though, message delivery is out of your control. You have no idea if a message is delivered or not. You can 'queue' tons of messages, and ZeroMQ won't tell you that those messages didn't get delivered. It's cool, but it's not a silver bullet. Contrib may be a place for it though. That is one of the common misconceptions. On the contrary - it is exactly thanks to ZeroMQ, that you have much MORE control over what is going on in your messaging architecture, NOT LESS. In sharp contrast to, say, RabbitMQ for AMQP, you are not locked into an implementation, or a strict protocol-spec - it is completely customizable. RabbitMQ simply implements the AMQP protocol-spec, so it MUST notify the senders about recipient's received message - it's a mandatory requirement in the QoS policy of the protocol. ZeroMQ CAN also do this, it is just NOT MANDATORY. The ability to submit to a recipient without it even being active, is a FEATURE, NOT a PROBLEM. It just means that a sending server may be set to have it's out-going sockets queued, so whenever the target-recipient comes on-line, he starts receiving the messages in the out-going queue. When that happens, there is nothing preventing from the recipient from sending back replies for assuring the message was received - in fact, by default most typologies are set so that every message-received, is echoed back to the sender, so it can cross-reference and make sure that the message goth through. Remember, both AMQP AND ZeroMQ are already being used in banks for transferring transactions, so the QoS is very reliable, if that is what you want - you just don't HAVE to use it, if you don't want to. -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop
[web2py] Re: ZeroMQ in web2py
On Thursday, April 11, 2013 10:57:44 AM UTC-7, Derek wrote: TCP is only the transport - you still have your application-specific protocols that you'd need to write. If your logstash gets a message like 'addlog i like pizza 07-11-2011' it doesn't know whether 'i like pizza' is an application, a status, or a priority level. So ZeroMQ isn't going to make connecting differing things easier. You still need your application layer messages. For all Logstash would know, 07-11-2011 could be July 11th, or November 7th. If you have a 'version control' ZeroMQ socket, who's to say it's going to use Git? What about Mercurial? Svn? All of those speak different languages, so you won't make anything easier by using ZeroMQ. In fact, you'd make it more difficult since not all those systems would have a ZeroMQ endpoint. Sure, if they had them, then good, but you'd still need to have your application level protocol, and good luck getting all the source control vendors to agree on a single protocol. Also, fwiw I use fossil http://fossil-scm.org. ZeroMQ is NOT a protocol - It is a messaging-library - it already has it's own application-level protocol, in the form of an API. And it is also NOT a replacement for TCP, it is NOT another TCP-kind-of-socket. It is a library built on-top of TCP/UDP, using a software stack. AMQP IS a protocol, but it is not the same as the one ZeroMQ has internally. Of course, you CAN layer a message-format on top of that, to agree on semantics within the messages themselves. But that can be a simple manner of reading a short documentation of any application, to know in what format the application is expecting the messages to be in. That will exist in most cases anyway, but that is not to say that nothing can be gained by layering on-top of a TCP socket... In TCP, you have to do much lower-level stuff, such as structuring bytes, defining message byte-sizes, and in effect defining a messaging protocol, in it's lower-level - like, what defines a message-body, or what defines a receiving socket?, or what defines a queue?, or what defines a publish/subscribe socket?, etc. Then there's defining frames of data-packets, making sure it is all bug-free, and performant, utilizing existing low-level system APIs in the most efficient way to achieve maximum performance, with connection-pooling, and the list goes on... The work that has been done within ZeroMQ is astounding - I think you are not giving it it's due credit... It is much faster than the native python-implementation of a bare-bone TCP socket, and is actually built on-top of it (in it's system-level manifestation, it's a c-compiled module, it is not actually using a TCP socket of the python level). Another benefit of it, is that although it's not a protocol per-say, it is still extremely wide in the amout of programming-languages it support, and already has binding for basically any common language in use today. Here is a good talk about it: http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-advanced-network-architectures-with-zeromq-4896861 As for Logstash, the whole point of the concept of centralized Logging systems, is that every application has it's own log-format... The whole point of using any centralized-logging system, is to be able to translate every format of any application-log, into a consistent interpretation - it is done by building plug-ins in the form of a declarative-language text-file, in which you describe gor each target-application, how it's log-message is to be interpreted, by tagging the components of each message-part. After you have a plug-in for an application, you add in to a plug-in pool somewhere and others can us it for that application. After a while, you get what exists today - a library of plug-ins that cover most of the common applications that exist - you just download the ones you need, and everything works. Then, logstash can cross-reference logs from different applications, into a chronological time-line, so you see what happened, and in what order. in a cross-application kind of fashion. Here is a great talk about it: http://www.youtube.com/watch?v=RuUFnog29M4 The point of using ZeroMQ for this, is not to resolve the issue of defining a consistent protocol of semantic-communication of the data within the messages (that will most probable will never happen...), but it is to have a consistent API for establishing a physical-connection AND a messaging-semantics between different applications. There is a big gap between a TCP socket-definition, and a messaging-semantic definition, and ZeroMQ fills this gap very well. It is what allows a developer to push the worries of the physical-connection AND messaging-protocol down the abstraction-stack, so he can focus his efforts in bridging the logical semantic-differences, which will always exist. -- --- You received this message because you are subscribed to the Google Groups
[web2py] Re: ZeroMQ in web2py
I really like 0MQ too but I would like to understand a typical test case of integration with web2py. Consider the scheduler for example. The bottle neck is not distribution of tasks (which 0MQ would handle great) but the fact that tasks and main app need to access the database. If the workers do not need to access to the database (for example tasks that send a simple email) then 0MQ would provide a benefit but the problem is no longer web2py specific. In which situation would use 0MQ with web2py? Massimo On Wednesday, 10 April 2013 17:06:59 UTC-5, Arnon Marcus wrote: I'l like to start a discussion about working-out an integration implementation for ZeroMQ in web2py. If not as a built-in, than at least as a contrib. If nothing else, than at the very least a recipe and/or examples, and added documentation about how to activate/deploy the integration. ZeroMQ is, to me, one of the coolest things that have happened to the software industry in recent decades... Gone are the days of monolithic systems - open-source has changed the software world entirely, and there is no going back - the days are the days of the integration,hybrid-system, modularity, and variety of components, and ZeroMQ is fast becoming the best candidate for filling the gaps and being the glue that can best bind all things together - beyond the concept of a static-centralized message broker. Fast, efficient, flexible, easy to use, decentralized, free, cross-platform, poliglot, and for not just for messagins, but also for rpc and REST (the concept, not the protocols), and not even just for networking, but also for itc and ipc. I think the more software will esit that has it buil-in, the more easy it will become to build dynamically changing modular software infrastructures. Now, the first thing that I am personally interested about, is to have a 0MQ-RPC service alongside the existing services. There are already existing python modules that do that, it is only a matter of picking one and integrating is as just another service. For example: https://github.com/dotcloud/zerorpc-python In addition, there are initiatives for having ZeroMQ-complaint sockets on the client-side. Here are a few examples: http://vimeo.com/41410528 http://www.zeromq.org/topics:0mq-over-http http://blog.fanout.io/2012/09/26/make-http-requests-over-zeromq-with-zurl/ Web2py can be another one of the frameworks that implement a ZeroMQ bridge between clients and the rest of the back-end software infrastructure. What do you say? -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[web2py] Re: ZeroMQ in web2py
I think the more software will esit that has it buil-in, the more easy it will become to build dynamically changing modular software infrastructures I have no idea what you are trying to say there. Anyway, yes, it's cool, you don't worry about message delivery because it's completely out of your control. That's the exact problem with it though, message delivery is out of your control. You have no idea if a message is delivered or not. You can 'queue' tons of messages, and ZeroMQ won't tell you that those messages didn't get delivered. It's cool, but it's not a silver bullet. Contrib may be a place for it though. On Wednesday, April 10, 2013 3:06:59 PM UTC-7, Arnon Marcus wrote: I'l like to start a discussion about working-out an integration implementation for ZeroMQ in web2py. If not as a built-in, than at least as a contrib. If nothing else, than at the very least a recipe and/or examples, and added documentation about how to activate/deploy the integration. ZeroMQ is, to me, one of the coolest things that have happened to the software industry in recent decades... Gone are the days of monolithic systems - open-source has changed the software world entirely, and there is no going back - the days are the days of the integration,hybrid-system, modularity, and variety of components, and ZeroMQ is fast becoming the best candidate for filling the gaps and being the glue that can best bind all things together - beyond the concept of a static-centralized message broker. Fast, efficient, flexible, easy to use, decentralized, free, cross-platform, poliglot, and for not just for messagins, but also for rpc and REST (the concept, not the protocols), and not even just for networking, but also for itc and ipc. I think the more software will esit that has it buil-in, the more easy it will become to build dynamically changing modular software infrastructures. Now, the first thing that I am personally interested about, is to have a 0MQ-RPC service alongside the existing services. There are already existing python modules that do that, it is only a matter of picking one and integrating is as just another service. For example: https://github.com/dotcloud/zerorpc-python In addition, there are initiatives for having ZeroMQ-complaint sockets on the client-side. Here are a few examples: http://vimeo.com/41410528 http://www.zeromq.org/topics:0mq-over-http http://blog.fanout.io/2012/09/26/make-http-requests-over-zeromq-with-zurl/ Web2py can be another one of the frameworks that implement a ZeroMQ bridge between clients and the rest of the back-end software infrastructure. What do you say? -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[web2py] Re: ZeroMQ in web2py
If you're talking about a webserver serving a database-backed website, I see no need to use it. Perhaps some esoteric uses could be found for it. On Wednesday, April 10, 2013 4:28:08 PM UTC-7, Massimo Di Pierro wrote: I really like 0MQ too but I would like to understand a typical test case of integration with web2py. Consider the scheduler for example. The bottle neck is not distribution of tasks (which 0MQ would handle great) but the fact that tasks and main app need to access the database. If the workers do not need to access to the database (for example tasks that send a simple email) then 0MQ would provide a benefit but the problem is no longer web2py specific. In which situation would use 0MQ with web2py? Massimo On Wednesday, 10 April 2013 17:06:59 UTC-5, Arnon Marcus wrote: I'l like to start a discussion about working-out an integration implementation for ZeroMQ in web2py. If not as a built-in, than at least as a contrib. If nothing else, than at the very least a recipe and/or examples, and added documentation about how to activate/deploy the integration. ZeroMQ is, to me, one of the coolest things that have happened to the software industry in recent decades... Gone are the days of monolithic systems - open-source has changed the software world entirely, and there is no going back - the days are the days of the integration,hybrid-system, modularity, and variety of components, and ZeroMQ is fast becoming the best candidate for filling the gaps and being the glue that can best bind all things together - beyond the concept of a static-centralized message broker. Fast, efficient, flexible, easy to use, decentralized, free, cross-platform, poliglot, and for not just for messagins, but also for rpc and REST (the concept, not the protocols), and not even just for networking, but also for itc and ipc. I think the more software will esit that has it buil-in, the more easy it will become to build dynamically changing modular software infrastructures. Now, the first thing that I am personally interested about, is to have a 0MQ-RPC service alongside the existing services. There are already existing python modules that do that, it is only a matter of picking one and integrating is as just another service. For example: https://github.com/dotcloud/zerorpc-python In addition, there are initiatives for having ZeroMQ-complaint sockets on the client-side. Here are a few examples: http://vimeo.com/41410528 http://www.zeromq.org/topics:0mq-over-http http://blog.fanout.io/2012/09/26/make-http-requests-over-zeromq-with-zurl/ Web2py can be another one of the frameworks that implement a ZeroMQ bridge between clients and the rest of the back-end software infrastructure. What do you say? -- --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
