Is there a way of integrating Zope 2 (2.13.19) using Python 2.6.8 with socket-io ?
I've found https://python-socketio.readthedocs.io/en/latest/ but it doesn't seem to fit the requirement.
Zope contains a traditional HTTP server, but you could write a ZEO client that would use the socketio library and integrate with Zope's transactions.
It seems that at least the version which is using eventlets should be possible to implement under Python 2.7.
https://python-socketio.readthedocs.io/en/latest/intro.html#server-examples
What Plone version are you using?
I used a slightly different approach in the past, to realize this. I was using a small Pyramid app, which was implementing the socketio (similar to the WSGI way of this library) and was subscribing a Redis PubSub channel. Plone was using event handlers to send messages to the Redis channel which would then consumed by the Pyramid app and send to the socket.
This above library should work and the easy way to use it, would be the same way i did, as a WSGI app together with messaging.
Starting with the upcoming Plone 5.2 you can run Plone on WSGI even under Python 3. This might be a better fit, together with the WSGI app which provides the socket.io support.
The library supports also Redis for multi-server support.
Optional support for multiple servers, connected through a messaging queue such as Redis or RabbitMQ.
The integration with Zope transactions is doable, I had to do that for the Redis messages too.
in the community forum is an interesting thread on that topic too:
https://community.plone.org/t/plone-socketio-websockets/6453/14
Related
I've been reading about websockets and SaaS like Pusher and Socket.io recently, while working on my Laravel chat practice application. What I don't understand is, why do we need external software to establish a websocket connection? Can't the server code like Laravel just directly establish the connection with the front-end like Vue.js? Why does it have to go through the middleman like Pusher and Socket.io? Sorry for the noob question.
It doesn't have to.
Those pieces of software just happen to make it trivial to work with the Websocket protocol.
Remember, Laravel is an opinionated framework. This means that it will pick and choose its own libraries to abstract away these kinds of concepts for you so that you don't have to worry so much about what's going on under the hood.
Basically, there are two components that you need in order to be able to work with Websockets:
A Websocket Server
A Websocket Client
The reason Laravel doesn't communicate directly with the front-end using Websockets is because Laravel itself isn't a Websocket server. At least, not really. And while PHP does have support for working with the Websocket protocol - and even some libraries to leverage it a little more nicely - it just isn't used to handle long-lived processes as often as other languages.
Instead, Laravel uses the Pub/Sub functionality that Redis provides to listen to events that occur through Redis and the Predis library. The reason why it does this is because Laravel is better-suited as a middle-man for the websocket server, and all connected clients.
In this way, Laravel can both pass information up through to the Websocket server using Broadcasting Events, as well as receive event information from the Websocket server and determine if users have the ability or authorization to receive them.
If you don't want to use Pusher, there is a library that will allow you to run your own Websocket Server specifically for Laravel called Laravel Echo Server.
Under the hood, this library still uses Socket.io and Redis in order for all moving parts to communicate with each other seamlessly in a Laravel web application. The benefit here is that you won't need to worry about the number of messages being sent by the server.
The downside is that you now have to know how to manage and maintain this process on your server so that the Websocket Server will know to turn on every time you restart your server, or if a failure happens, etc.
Check out PM2 to learn more about running and maintaining server daemons.
If you don't agree with Laravel's opinions on how to handle Websockets, then you could theoretically use any other server-side language to handle the websocket protocol. It will just require a greater working knowledge of the protocol itself; and if Laravel needs to work with it, you'll have to know how to write the appropriate Service and Provider classes to be able to handle it.
Short answer? You don't have to use them. Knock yourself out writing your own server and client side websocket implementation.
Longer answer.
Why use Laravel? I can do all that with straight up PHP.
Why use Vue? I can do all that with vanilla javascript.
We use libraries and frameworks because they abstract away the details of implementation and make it easier to build products. They handle edge cases you don't think of or things you don't even know that you don't know about because they are used by thousands or millions of developers and all the knowledge and bugs they have encountered and fixed are baked into the implementation.
This is one of the hallmarks of software engineering, code reuse. Don't repeat yourself and don't write any software you don't have to. It allows you to focus on building a solution for your particular requirements, and not focus on building a bunch of infrastructure before you can even build your solution.
I've never used Pusher, but it looks like, yes, it is a SaaS product. But Socket.io is open source.
I'm building a fairly simple application with Autobahn for WebSocket functionality. It's very similar to a chat server, but one thing I need to do is understand how to accomplish is how to essentially share resources between the WebSocketServerFactory object and my Flask application. The example here:
https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/websocket/echo_wsgi
shows how to combine both Flask and Autobahn, but in my particular use case, I want to be able to dynamically add a chat room when triggered by an authorized call from the Flask component. Is there any sort of best practice on how to go about communicating between the two components in Autobahn?
Flask is based on WSGI, which is a fundamentally blocking API. This doesn't blend well with Twisted or asyncio (the 2 asynchronous network frameworks supported by AutobahnPython).
Here are 2 options:
using Twisted callFromThread to communicate from a background thread running WSGI to the main thread running Autobahn
Twisted Klein http://tavendo.com/blog/post/going-asynchronous-from-flask-to-twisted-klein/
I'm looking to prototype a web app that will use sockets to push a gentle stream of messages to mobile web app clients. I want to pick an architecture that will work for a large number of clients if/when it moves to production (so i dont have to change later)
I'd like to start with rails because its familiar and has a strong structure from the go meaning easier to prototype. I think Faye will provide what i need in terms of a pub-sub layer but am I going to create a bottleneck by using ruby and the high number of socket connections, or will Faye isolate/protect Ruby server from that load, if you follow?
At the outset the load will not be significant so it won't matter, i just don't want to be hobbled later on when there are a lot of socket connections and i wish i used node.js ! Server side JS would be fairly new to me but I guess there are benefits in that the JS app can include the client side also
Advice appreciated.
You can take a look at https://github.com/faye/faye-redis-node.
This plugin provides a Redis-based backend for the Faye messaging server. It allows a single Faye service to be distributed across many front-end web servers by storing state and routing messages through a Redis database server
Well, I have doubts about this technology, more precisely in its implementation, can not find good examples on the Internet, as it involves javascript and php, only, you would have some links where I can find this stuff really works and that ?
A great source for all things Comet is Comet Daily. Unfortunately it's not updated all that often any more but there are some fantastic old articles in there. It's contributed to by guys that have been developing Comet solutions for over 10 years.
Comet seems to get incorrectly bundled as meaning just one particular connection mechanism is used, but it's actually a paradigm for realtime push from server to client. Comet servers can use HTTP Streaming, HTTP Long-Polling, classic polling and WebSockets.
If you are interested in the latest Push Technology then you should take a look at WebSockets which is a standardised approach to not only server to client push, but also bi-directional realtime communication between servers and clients (web browsers and other clients).
Some current trending push technologies are:
socket.io
Hosted WebSockets services such as Pusher - who I work for
Faye for self hosted Ruby or Node dev
SignalR for IIS and .NET
There are many more and more information on realtime web technologies can be found on this guide.
If you want to use PHP you could struggle to build an application using realtime Push which will scale above a small number of connections. Have a read through this question on concurrency - How to implement event listening in PHP for more information.
Do you specifically mean Ajax push? Because a more common method is comet push, I has been a while I worked with this, probably more browsers support this.
A good implementation can be found here:
http://www.ape-project.org/
Well it's called Ajax Push engine, so I suppose that is what you are looking for.
If you work with Java/Scala/Ruby/Groovy, take a look at Atmosphere, which is being actively developed/used (I'm the creator). There are many samples available.
Check out the Bayeux Protocol and CometD implementation in Java & Javascript.
From http://cometd.org/ :
CometD is a scalable HTTP-based event routing bus that uses a Ajax Push technology pattern known as Comet.
Here the link to an interesting article describing the technologies involved and a comparison of CometD and Atmosphere implementations.
Socket.IO seems to be the most popular and active WebSocket emulation library. Juggernaut uses it to create a complete pub/sub system.
Faye is also popular and active, and has its own javascript library, making its complete functionality comparable to Juggernaut. Juggernaut uses node for its server, and Faye can use either node or rack. Juggernaut uses Redis for persistence (correction: it uses Redis for pub/sub), and Faye only keeps state in memory.
Is everything above accurate?
Faye says it implements Bayeux -- i think Juggernaut does not do this -- is that because Juggernaut is lower level (IE, I can implement Bayeux using Juggernaut)
Could Faye switch to using the Socket.IO browser javascript library if it wanted to? Or do their javascript libraries do fundamentally different things?
Are there any other architectural/design/philosophy differences between the projects?
Disclosure: I am the author of Faye.
Regarding Faye, everything you've said is true.
Faye implements most of Bayeux, the only thing missing right now is service channels, which I've yet to be convinced of the usefulness of. In particular Faye is designed to be compatible with the CometD reference implementation of Bayeux, which has a large bearing on the following.
Conceptually, yes: Faye could use Socket.IO. In practise, there are some barriers to this:
I've no idea what kind of server-side support Socket.IO requires, and the requirement that the Faye client (there are server-side clients in Node and Ruby, remember) be able to talk to any Bayeux server (and the Faye server to any Bayeux client) may be deal-breaker.
Bayeux has specific requirements that servers and clients support certain transport types, and says how to negotiate which one to use. It also specifies how they are used, for example how the Content-Type of an XHR request affects how its content is interpreted.
For some types of error handling I need direct access to the transport, for example resending messages when a client reconnects after a Node WebSocket dies.
Please correct me if I've got any of this wrong - this is based on a cursory scan of the Socket.IO documentation.
Faye is just pub/sub, it's just based on a slightly more complex protocol and has a lot of niceties built in:
Server- and client-side extensions
Wildcard pattern-matching on channel routes
Automatic reconnection, e.g. when WebSockets die or the server goes offline
The client works in all browsers, on phones, and server-side on Node and Ruby
Faye probably looks a lot more complex compared to Juggernaut because Juggernaut delegates more, e.g. it delegates transport negotiation to Socket.IO and message routing to Redis. These are both fine decisions, but my decision to use Bayeux means I have to do more work myself.
As for design philosophy, Faye's overriding goal is that it should work everywhere the Web is available and should be absolutely trivial to get going with. I'ts really simple to get started with but its extensibility means it can be customized in quite powerful ways, for example you can turn it into a server-to-client push service (i.e. stop arbitrary clients pushing to it) by adding authentication extensions.
There is also work underway to make it more flexible on the server side. I'm looking at adding clustering support, and making the core pub-sub engine pluggable so you could use Faye as a stateless web frontend for another pub-sub system like Redis or AMQP.
I hope this has been helpful.
AFAIK, yes, apart from the fact Juggernaut only uses Redis for Pubsub, not persistence. Also means client libraries in most languages have already been written (since it just needs a Redis adapter).
Juggernaut doesn't implement Bayeux, but rather has a very simple custom JSON protocol
I don't know, but probably
Juggernaut is very simple, and designed to be that way. Although I haven't used Faye, from the docs it looks like it has a lot more features than just PubSub. Being built on top of Socket.IO has it advantages too, Juggernaut's supported in practically every browser, both desktop and mobile.
I'll be really interested in what Faye's author has to say. As I say, I haven't used it and it would be great to know how it compares to Juggernaut. It's probably the case of using the best tool for the job. If it's pubsub you need, Juggernaut does that very well.
Faye certainly could.
Another example of a similar project on top of Socket.IO:
https://github.com/aaronblohowiak/Push-It