What is the current state of Push technology in web development? I heard solutions like Comet as described in this article are not used anymore and instead WebSocket is the future for this kind of features, but it's only supported in Chrome and Safari.
What is the best technique to use?
I'm developing a game where many players (between 2 and 4) can seamlessly interact with each others. I'm using PHP server side and Jquery in client side.
There is a solution that will work in older browsers. I don't know the finer details but I'm sure liking the blurb: (see query-graceful-websocket)
The Graceful WebSocket
So, you want to start building realtime event driven applications using the new HTML5 WebSocket API?
You want it to work in all browsers, no matter if they have WebSocket support or not
You don't want to rely on proprietary technology such as Flash to provide a fallback
And naturally, you don't want to write more than one implementation
Introducing, the gracefulWebSocket jQuery plugin:
Implements the w3c WebSocket interface
Wraps the native WebSocket if support is detected
Provides a default fallback using traditional AJAX polling over HTTP
Requires no extra code on the frontend, allows you to target the WebSocket API today and let users take advantage of it as more browsers add support.
Default fallback behavior can be overridden by plugin options
https://github.com/ffdead/jquery-graceful-websocket
I use beaconpush (Software as a Service) easy to implement, nice API, interesting functions - definitely worth a look.
Related
I need for a project to build a live chat with:
group chat room
private chat (user-user);
web site interface;
mobile interface;
others information (profile etc).
I want to start obviously from the server: any PHP framework or tutorial to do this ?
Otherwise, any full-solution (but customizable) with web site + mobile compatible ?
Use XMPP Server (XMPP server uses Socket programming, so once a connection will be establish, then it uses that connection each and everytime, you no need to create connection everytime, like HTTP).
Or Use GCM (Using Push Notification you can send and receive messages as well).
Here are some Source Code - Github
Source from google
Hope it helps.
http://vidorsolutions.blogspot.pt/2011/01/writing-xmppjabber-chat-application-for.html
This would be the best place to start!
Have fun building the app!
Also if you really want to get deep into it, Xabber source code will prove of great help.
XMPP is a communication protocol for message-oriented middleware based on XML (Extensible Markup Language). In plain words it is a protocol used for instant messaging.
While APNS and GCM are services used to set up push notifications for your apps.
So, it's a bit different.
I believe building a chat app from scratch is not an easy task for you.
So, I'd recommend using a ready backend and concentrate on client-side implementation of your app.
For backend you need to choose a provider with the set of features most suitable for your project and then start app development with the API provided by your backend provider. You might find this article useful when choosing.
It seems you are looking to get going fast on your chat implementation...the xmpp implementation is one way. Firebase provides another. Having implemented messaging via xmpp as well as firebase, I can offer up this tip: stable connectivity and auto-reconnect logic in an openfire+SMACK implementation is not particularly reliable. I have had recurring troubles maintaining connection in the face of drop offs; updates in Openfire that may or may not conform to the older SMACK library versions are not helpful (no one guarantees for conformity - you are on your own). Others with more xmpp-based experience may attest to these difficulties. Firebase is not without its own challenges but I found them manageable. I also recommend you checkout at least one opensource chat library implementation via firebase (github link being one such). With firebase the connectivity issue largely goes away and a host of new options open up. I prefer if the backend is fully taken care of by the library provider so we only need to focus on UI. Hope this is helpful.
I have been researching WebSockets for a few hours but can't seem to understand why you would need both client and server side libraries to help with WebSockets implementation?
I am using PHP so from research it seems like Ratchet is the most popular. But why would you need a server side implementation of WebSockets when server side HTML5 supports WebSockets? Can you build a chat system without the use of libraries at all? And can you build a chat system, for example, without any support on server-side, i.e. just with a jQuery library?
And how does WebSockets relate to node.js? I find it hard to get to grip with server side running JavaScript to send responses to a JavaScript front end.
Also, is this: https://code.google.com/p/phpwebsocket/ library a similar thing to Ratchet?
Does Google Chrome web store support server sided technologies such as PHP or Python?
I am currently making a productive web application which i have already implemented in python but i wish to give it a nice little web application interface and also harness the power of PHP...
Does Chrome support Python or PHP; or does Chrome even support Server sided scripting?
I am learning how to develop chrome apps from here...
If a member is aware of any better tutorials please inform me...
Or is it that i just have to build a normal web applications and add a logo and manifest and zip it and publish it?
Thankyou...
The platform supports server-side technologies the same way a C++ or Java application would support them: through HTTP (probably RESTful) interfaces that the server side of your app (if any) exposes. For example, your app might make a request to http://example.com/api/foo/bar/baz?param1=123¶m2=456, and might get back a JSON response that your app would then parse. It doesn't really matter which server-side technology you're using, because the API looks the same from the app's perspective.
If you're asking about PHP, Ruby, Python, Go, node.js, etc., running on the user's machine as a client-side app, no, that's not how Chrome packaged apps work (though in theory one could get one of those environments running as a NaCl module that then generates client-side code). Instead, you write code in a very similar way to how you'd write a pure AJAX app: in JavaScript, without navigation, with the content/data being fetched in a RESTful fashion from whatever server/service you use (or none in the case of something like a calculator or simple game that doesn't talk to the network at all). Incidentally, we're finding that very AJAXy apps are relatively simple to convert to packaged apps.
Check out all the samples at https://github.com/GoogleChrome/chrome-app-samples to get more an idea of the shape of the platform.
We are making a website where we are trying to develop a chat application, we have already built one using Comet, however due to speed factors we decided to make one in XMPP.
However, with HTML5 alive and living and the new websockets technology in existance, should we leave XMPP and try making using Websockets instead?
So my questions are :
I can make a mobile app and connect it to XMPP on my server, is
there a way to connect to a websockets based chat app via phone? (
For example Smack library for android, is there something similar
for websockets based app?
Is there a fallback option say if the person is using an old browser
for the websockets based chat app?
Which has more overhead and which technology is faster or better?
Also, it may be said that XMPP is a tried a tested technology, it still needs many libraries right? Such as the Strophe.js flXHR etc. right? But isin't HTML5 built for this type of thing without any eternal libraries etc?
Regards,
The XMPP wikipedia page has a section on XMPP via HTTP and WebSocket transports. The last paragraph states:
A perhaps more efficient transport for real-time messaging is WebSocket, a web technology providing for bi-directional, full-duplex communications channels over a single TCP connection. Experimental implementations of XMPP over WebSocket exist, and a (now-expired) Internet-Draft documenting this approach was published at the IETF but not yet standardized.
WebSocket is a protocol for messaging and as such XMPP can be implemented over WebSocket. If WebSocket sub-protocols are taken further we may even see native support for this. But until then the WebSocket connection would simply act as the low-level transport for the XMPP protocol messages.
So, it's not a question of "XMPP or WebSocket". If XMPP fits your requirements well then I'd look for an solution that uses WebSockets (and has appropriate HTTP fallbacks) and provides XMPP support.
I'm choosing between AMQP (RabbitMQ) vs XMPP (eJabberd) for my browser-based flash-free javascript powered real-time turn-based game. I don't know much about AMQP and XMPP protocol. I would like to use PHP for user-authorization and some data store-retrieve with MySQL. As far as I found out, RabbitMQ has PHP clients but eJabberd not.
What I understood is javascript client calls PHP script and manipulate necessary processing and then pass to AMQP or XMPP server to pass the data to opponent player. There is a good book 'Pro XMPP Programming with JS and jQuery' from Wrox but there is no example with PHP. So following are my questions.
1) Which protocol is suit for my game?
2) Shall I choose RabbitMQ just for it's PHP client support?
I've had fairly good success implementing an XMPP client in Javascript by using HTTP Bind approach to XMPP BOSH. I don't know about AMQP, but for client-side access, I love XMPP. A few words why.
ejabberd already includes BOSH support, and to use with Javascript (and presumably Flash) you just need to direct your server to redirect requests to port on which you configure ejabberd to listen for HTTP requests. (And even this only because Javascript security model in today's browsers forbids Javascript requests to different domains and even different ports.)
Since XMPP is a bunch of quite trivial small XML documents, it should be fairly easy to encode them in any language you pick.
Since it's widely supported, you might be able to avoid requiring your users to register with your service, which they will most certainly appreciate.
Implementing XMPP means you can trivially add instant messaging support to your game, with federationing to the rest of the Jabber network (including Google Talk).
Since I don't know anything about AMQP, I cannot compare them -- but I can say why I'll always first consider XMPP for my future multiplayer projects.
My personal reason for choosing ejabberd is simple -- it's super easy to install and configure on Debian. I'm almost completely unfamiliar with Erlang and Java; what I understand, however, about Erlang is that it makes scalability easy to achieve, and ejabberd people say they have achieved it.
If you want to do server side logic checking, I'm afraid I don't know of any good method. I'd go with a proxy PHP script doing sanity checking on the incoming XMPP BOSH message, then forwarding it to the server, instead of just forwarding it via Apache's mod_rewrite.
As mentioned above, you will definitely have to do proxying of some sort (with mod_rewrite or with PHP or in some other way) since the XMPP server will listen on a different port than the "main" web server, and Javascript cross-domain security model does not allow doing XMLHTTPRequest on a different port.
So, sanity checking might be easiest done while relaying BOSH requests to XMPP server of your choice. Digging into the server software might not be the best way to do this type of checks. It would take long, and would probably make it harder to integrate with the rest of your game.
Alternatively, I stumbled upon an answer that mentions XMPP components and ejabberd modules. This will be an interesting read for me, too.
Good luck, and be sure to drop a comment with the name of the game when it's done -- I'd love to see it :-)
I just noticed someone else posted a very similar question to yours. Its answers contain some more interesting info for you.
On using XMPP with Flash:
You could nevertheless use HTTP binding (BOSH) with Flash. In fact, while HTTP binding allows Javascript to access XMPP, it was conceived for a variety of applications, such as mobile connections that can often break.
I mostly figured out how to establish the connection by observing communications between web-based client JWChat and ejabberd (for info on BOSH), and then communications between cross-platform client Psi and ejabberd (for info on protocol itself). With JWChat and WebKit's Web Inspector or with Firebug for Firefox, one can easily track XMLHttpRequests being done towards the server. With Psi, one can turn on the XML console and read the communications log. Combined with prototyping a client in a language of your choice, studying BOSH and XMPP turned out to be very easy.
Also, following XEPs are useful: XEP-0124, XEP-0206.
O'Reilly book that I'm reading right now, "XMPP: The Definitive Guide" (P. Saint-Andre, Kevin Smith, Remko Tronçon; much cheaper on Apple's App Store) also gives you the feeling "why things are done the way they are", and documents many small things and various applications of XMPP.
After that, implementing a BOSH-based client could turn out to be rather easy. I have no experience with coding with Flash apart from making a button play and pause, so take this with a grain of salt :-)
As someone mentioned, you need to consider the client-to-server part; that seems of more importance.
It sounds like you already have the best book on the subject (Jack Moffit's XMPP + JS book) and I would definitely say that's the technology to go with.
Also you get user authentication, encryption and all the many XMPP protocol extensions on top of that, as the book will describe.
Even although I can't recommend any PHP-XMPP clients, I don't think you'd necessarily have the same level of features out-of-the-box with AMQP.
Also, if you're versed in other languages, and depending on the amount of game logic required, you could write an XMPP server component. See this prior question about XMPP + gaming for info:
XMPP C# Interaction
AMQP has not yet reached version 1.0 and has some possible design issues around it. There are XMPP clients for PHP so if I were you I'd give that a try first.