I'm trying to create a website like Ustream using ruby on rails.
I want users to be able to turn on their webcams and broadcasts live. I also want them to be able to send out a link to their live broadcast. The broadcast will need to work cross-browser also.
How can I do this effectively using ruby on rails?
Please be as detailed as possible. I'm looking for most simple and efficient solution.
Thanks in advance.
Your question is pretty vague, so I apologies if this is not as specific as you may hope
Live Streaming & Rails
Rails really isn't designed for live-streaming
It's MVC structure is best used to interact with large data-sets, and is better suited to handling things like authentication, API's, data-driven applications, etc
The live-streaming functionality you seek is more in the realm of node.js & socket.io, more specifically websocket architecture, whereby two connected devices can share data across a single connection
There are a number of options available, but they are limited unless you go down the proprietary route:
TokBox
TokBox is the safest bet for Rails apps - it uses a third-party API to connect the devices, and implements the connection on the front-end with Javascript & flash. We have actually implemented this before, and it's very simple to do - it's all explained here
Tokbox is now owned by Telefonica, and I believe are investing heavily to make their technology better available & higher quality to developers. So we'll have to see how it goes
WebRTC
This is more like a driver, but is the best quality of all the options. The only issue is that implementing this technology is actually pretty hard. Here is an overview for you:
WebRTC is an open-source project enabling plugin-free, Real Time
Communications (RTC) in the browser. It includes the fundamental
building blocks for high-quality communications such as network,
audio, and video components used in voice and video chat applications.
Recommendations
Having implemented TokBox before, I'd recommend you look at that. You can see a tutorial about it here
Related
I am looking to extend a web application using the new real time API in order to support collaboration (javascript). For that purpose I would also like to include a chat which will be available to users collaborating on same document. After extensive search I cannot find parts of the Drive API that can be used for this. Furthermore none of the open-source examples provided by google implement chat functionality.
Is there existing services/code that I can use to intergrade
chat into my application or I would need to implement it?
As mentioned before, the chat should be available to those collaborating on same document.
p.s I do not require any special features, just a simple chat as the one found in google docs etc.
Right now I don't know of any out-of-the-box solution to this problem. Some people have implemented chat in a realtime document by just placing the chat messages in the realtime data model.
This works fine so long as you don't also want to use undo/redo feature. If you are using undo/redo, then people would end up undoing the chat messages.
We are interested in adding some better support for this eventually, but no promises on anything in the short term.
You will need to build your own chat system, as Google just killed off XMPP support on the Chat API (which largely kills off the use of the API). The new Hangouts API does not provide access to Chat ( though some additional methods may come in handy: https://developers.google.com/+/hangouts/ for the dev API).
You are therefore left to your own devices. Fear not, however, writing a chat system is pretty easy. I am about to release a (mostly free) service to do so, so if you want to not have to write the code for it, I can keep you posted.
If, however, you'd prefer to build the code for it, you will most likely want to look into either socket.io or postal.js. both provide the same thing: a pub/sub model. From there, you will need to implement a choice of either:
Long polling: supported by all browsers but a bit clunky
Websockets: not supported by IE8 and below
This will serve as your data transfer.
Two other possible options are paid services: you can retrofit RabbitMQ to do what you want to do (this, however, will seem clunky). You can also retrofit the Meteord daemon, which does what you want natively, but has an outdated JS library.
The keyword of all this is pub/sub, though.
I've just read about single-page web applications that expose a RESTful interface for retrieving the data - for example in JSON format, and that just provide a single HTML page referencing the Javascript file responsible for invoking the RESTful interface and building the web user interface dynamically in the client's web browser.
To implement this in Play, one should implement the controllers so that they return JSON instead of HTLM and implement some CoffeScript for rendering the user interface on the client side.
So far so good... but I'm wondering whether this design makes sense for large web applications since the amount of javascript code to be run on the client side would increase more and more.
My initial idea was to implement the web application using Play's template engine and then to provide a RESTful interface for Mobile apps.
Any suggestion, idea, or link to documentation that covers this topic would be really appreciated ;-)
The Play for Scala book has a chapter on this topic. They use a single view as an entry point, that's it.
As for large applications, that's a valid concern. For that you might want to use libraries such as RequireJS (which Play 2.1 has built-in support for), among others. You also might want to split your app into sub-modules to manage complexity. On the client side, you probably should use a framework, too, such as AngularJS.
Concerning Play there's not much left to say, it's a very good platform to expose RESTful JSON services. I recommend you take a look at the JSON documentation and also check out ReactiveMongo.
Providing a common REST API should work fine. At the moment I am working with a Play 2.0 server app for browser (Backbone etc) and iOS clients. The browser client is totally separate from the Play app and deployed independently.
I think there is some initial overhead compared to Play template approach but having just one set of controllers to test etc makes life easier.
Couple points to consider:
Client authentication. Preferably you would use the same way for all the clients.
At some point you might want to introduce some specialized REST API for one of the clients in order to save bandwith and number of requests. For example mobile landing screen is a typical candidate.
You need to document your REST APIs more detailed as the web client devs are not sharing the codebase.
I'm trying to put together a small(ish) summer school project for some of my advanced students and am researching how to do it best and what to use - hopefully somebody here could point me in the right direction.
What we are interested in is researching if HTML5 came far enough to create a real-time collaborative drawing whiteboard in it - purely by using web technologies without plugins (so CSS, HTML5/DOM and Javascript). What we'd ultimatelly strive for is this - for example have an online canvas/page on a central server displayed on a big screen in the classroom. Then our students/users would take out their smartphones, load the page in their mobile browsers (I'm perfectly ok with limiting this to webkit mobile browsers for now) and draw on their screens with touch/fingers (or on PCs with the mouse - guessing this doesn't make a lot of difference) and it would get updated in real time for everybody - both on their screens and on the central big screen in the classroom.
I'm guessing push/get requests would be too slow for this - could it be solved by websockets? Does anybody have any good JS libraries to recommend for this?
Also what would the ideal (but easier for students to understand) architecture look like. Lets say you have 30 simultaneous users in a clasroom - each of them would connect with websockets to the server and the server would pool/combine all of their requests into one and then return the combined file (some sort of minimal JSON or even just coordinates) for every connected user?
Would websockets and (I'm guessing) canvas be able to take this? So that everything still looks snappy? Are there (jQuery-like) JS libraries available to make our lives easier - or do you think its something thats too complex for a 2-week summer school project?
here's a tutorial describing how to create a multiuser whiteboard with javascript/html5/canvas:
http://www.unionplatform.com/?page_id=2762
the example uses a collaboration framework and server named "union platform". even if you decide to roll your own server and client framework, the messaging in the example should give you an idea of how to structure the code.
for an apples-to-apples speed comparison of websocket vs comet, see:
http://www.unionplatform.com/?page_id=2954
in my tests, a basic ping over WebSocket is normally about twice as fast as the ping over http. both websocket and coment are more than fast enough to create a collaborative whiteboard.
Definitely check this out:
http://wesbos.com/html5-canvas-websockets-nodejs/
For the networking side of things, try looking at node.js for the server, along with socket.io for the client.
As for the drawing itself, a few popular choices are processing, raphael and cakejs.
When it comes to the implementation, you may want to look at how networked games deal with similar issues (gamedev.stackexchange.com could be useful).
What you are going to be doing is essentialy the same as a simple top down multiplayer game, with each 'player' in this case being a students fingertip, and the 'level' being the canvas. You need to update the server as to their position and whether or not they are 'shooting' (drawing).
I'm guessing push/get requests would be too slow for this - could it be solved by websockets? Does anybody have any good JS libraries to recommend for this?
If you need real-time infrastructure I've created a list of real-time technologies which might be of use to you. These include hosted service, such as Pusher who I work for, and self-install technologies such as WebSocket and Comet solutions.
WebSocket sounds like the idea choice of technology for you since they have become part of HTML5 and offer the most efficient for of realtime bi-directional communication between a web server and a browser (or other clients).
Also what would the ideal (but easier for students to understand) architecture look like. Lets say you have 30 simultaneous users in a clasroom - each of them would connect with websockets to the server and the server would pool/combine all of their requests into one and then return the combined file (some sort of minimal JSON or even just coordinates) for every connected user?
It sounds like you should probably store the current state somewhere and on the initial load of the application display that state. Then use your real-time infrastructure to send deltas on that state, or if it's a drawing on canvas, just information on the line etc. that has been drawn and information about who drew it.
Would websockets and (I'm guessing) canvas be able to take this? So that everything still looks snappy? Are there (jQuery-like) JS libraries available to make our lives easier - or do you think its something thats too complex for a 2-week summer school project?
Real-time collaborative drawing is most definitely achievable and there have been a number of examples created of this. A google bring up a number of possibilities.
If this technology is completely new to you and you would prefer to concentrate on building the collaborative application then I would consider using a service for your app rather than going through the hassle of learning how to install and configure, or even code, your own infrastructure (I'm not just saying this because I work for such a service. I honestly think it makes the most sense).
I've got a couple projects that were built using hookbox to manage real-time message passing between web clients and servers. Hookbox was great -- it totally abstracted the transport layer, exposing a simple publish/subscribe interface across different channels with an elegant security system.
Unfortunately the hookbox project has rapidly fallen into disarray due to the original maintainer's unwillingness to even put in the effort to hand off ownership. (Grrr!) So it's hard to consider it a viable platform any more.
What's a good platform for providing real-time communication with web apps? Requirements:
Works seemlessly cross browser, using HTML5 websockets or COMET as available. Transport choice should be invisible to application layer. I don't care about ancient browsers (IE6)
Client access from both javascript and server-side systems (i.e. in php / python / ruby) -- this is critical
Provides a publish / subscribe metaphor with arbitrary payloads
Allows clients to see what other clients are connected to a channel, i.e. presence
Fine-grained access control through callbacks to any web application (nice to have)
I've heard that socket.io can do some of this, but I get the sense that it's at a lower layer of the stack. Can it connect to non-javascript libraries? Do auth?
I've had a very good experience with NodeJS and Socket.IO over the last 8 months. The server side component has been very stable for me - I can leave it running with a very high message volume and it's resident memory never really budges above 20MB. So far I've only been able to leave it running for about 4 weeks without terminating the server, but that was only because I needed to update my server side code.
Works seemlessly cross browser, using HTML5 websockets or COMET as available. Transport choice should be invisible to application layer. I don't care about ancient browsers (IE6)
Provides a publish / subscribe metaphor with arbitrary payloads
Socket.IO is also a fantastic piece of software. It under active development, and has a simple pub/sub style abstraction built in using EventEmitter (NodeJS) semantics of 'on' (subscribe) and 'emit' (publish). It is also very transparent on the client side regarding the transport being used. I used it primarily for the straight-up WebSocket support, but it can fall back to Flash based sockets, xhr-polling, and jsonp polling.
Client access from both javascript and server-side systems (i.e. in php / python / ruby) -- this is critical
NodeJS is JavaScript, running on the V8 engine. It has a ton of 3rd party modules that provide nice abstractions as well as interfacing with external components, such as a databases or message queues, among many other things. As far as hitting the system with php/python/ruby, it would work as with hitting any other server. Choose your method of communication (basic TCP/IP, or maybe HTTP POSTs or GETs, or even via filesystem) and NodeJS doesn't really care who is providing the data. Personally, I've implemented a C# client that is working great.
Allows clients to see what other clients are connected to a channel, i.e. presence
It doesn't not have any built in 'presence' logic, though with the built in 'pub/sub' logic already in place in Socket.IO, all you'd have to do is store state on the server so new clients can retrieve existing presence data. I've implemented my own basic pub/sub on the server that retains state, and all together (including the NodeJS server code, and the basic Socket.IO stubs) it was only 50 lines of JavaScript (including whitespace).
Fine-grained access control through callbacks to any web application (nice to have)
Not sure what you mean by 'Fine-grained access control through callbacks to any web application (nice to have)'. The pub/sub event/observer metaphor they have uses callbacks, so you hook specific actions to specific events.
Do auth?
I've had no need, yet, to do any auth for our systems, so I can't speak to it directly. However, if you browse the NodeJS modules you'll notice there are many auth modules available, including LDAP and OAuth, not to mention one module that claims to do "OpenId, Google, OAuth, Twitter, LinkedIn, Yahoo, Readability, Dropbox, Justin.tv, Vimeo, Tumblr, OAuth2, Facebook, GitHub, Instagram, Foursquare, Box.net, LDAP"
Although I haven't tried it yet, I started looking into Pusher for a Node Knockout 2011 entry. In addition to JavaScript, it supports the following non-js clients:
Objective-C
ActionScript
.NET & Silverlight
Ruby
Arduino
If messaging via a 3rd party is a possibility, you can try the service for free using their Sandbox plan (20 connections & upto 100K messages/day) and see if it meets your needs. (I'm a little uncertain about the "presence" requirement, though it may be covered in the docs.)
I recoment using node.js which has a lot of libraries for various things. One library for real time messaging is now.js. I don't have a lot of experience with this but have tried it and I would say it worked well and has everything you said you need.
I'm going to build an webbased application which is controlling and monitoring tons of realtime data. think about few thousand valves pipes pumps and sensors.
Please list a technology stack you would use to build a realtime website with an educated guess about performance. The environment is 'ideal' all openstandards are available. so no IE6 etc backward compatibility is needed. Current and future proof technologies please.
server side:
database web-server - which one / combination makes it easy to support real-time pushing of data?
client side:
what kind of client environment (javascript Libraries) support showing and updating tons of realtime data?
You can have a look at Goliath
I recommend you have a look into Socket.IO which works best with Node.JS and might be the best fit for handling many long lasting concurrent real time connections. I would say that the choice of the database depends more on where your real time data is coming from and how it is supposed to get in the database.
Me too. So I'm writing a frame work that can do that. It's based on lighttpd front end, and multiple fcgi backend servers. The original Android was also tested with another framework that is based on it. It's open source so you might want to use it as a starting point.
I haven't been able to write a realtime app, but I've dabbled a bit with http://socket.io/ and node.js, and it's a joy to get started with.
App engine has a js channel api which seems nice. You should take a look to see if hosting on app engine is a option.
If you're dealing with "real time" stuff server-side, I recommend clojure for managing concurrent state.