 Hey, my name is Pradeep, and you guys heard me probably. So I'm going to talk to you about XMPP and Ruby today. That's my contact chief. I work for Incridia. We're based out of Washington, D.C. You can sign up, I'm an Australian. Our flagship product is presently, and we also do crowdsides. We're based out of ComaTex. We're also based out of the area. Our employees are actually just kind of on the same level. So what is XMPP? How many here do you actually know of? So in someone who knows already what context they know of it, so traditional I am. That is sadly the only context that's known in a lot of people. I'm trying to change that. So XMPP actually stands for the extensible messaging and presence work. It is a class of software, I mean it falls on the class of software called Messenger and Team Metalware. We'll talk about that in a little bit. It's continually XML based. There are various XMPP servers, some of them are called EJVT or FIRE, Tegacea, etc. And of course most known for being the backend for a lot of XMPP systems. You can read more about it at xmpp.org where there are all the list of features and so on. The good thing about XMPP, there is actually quite a few, is first and foremost it's open, so if anybody can contribute with features and they can comment on features that are already submitted and you can write your own XMPP servers, everything is open. And it's also standardized by the Internet Engineering Task Force. It's also decentralized, you can run it on servers in America. And most of these servers can actually talk to each other. Ten years or so since we started. And now it's actually catching on a bit more. It's very customizable. It appears to be picked the right as an user. And since it's message based, it's actually pretty fast. Most of the servers are optimized for sending messages between various clients very quickly. The bad news is the XML is very repose. Some people call it over in America or in Minnesota. Documentation, it's readable and it's there, but it's not outside properly. Most of the people who actually focus more on the specifications than actually teaching people how to use it. But there are efforts going on right now to make it better. And on a larger network, since the presence is very important, there's a lot of data overhead, we're just sending around the presence data to see if somebody is online or not. Another thing that's being worked on is that you can't send unwanted binary data by transfers, because it's everything that's in the XML. So usually the authorities and the basics are extended to the standard. So a simple XMPP stands a little like that. You would have a message from a person to another person and there's a body that's as it basically gets. And how do you do that's what they call the JIT, which consists of the username and the server name. It's a unique identifier for every user. After that, that's the resource, which is an identifier for the client that is connected to the server at the time. You can have many resources, which means you can connect using multiple clients on multiple machines and you can set priorities so that certain clients get messages quicker than the other ones or so on. Just what you can send on a JIT job. So some XMPP features, you can find a big list on XMPP.org. The first and most important one is Creston and tell somebody's connected with an R. This one was a lot of overhead. Passing data around. Only people who need to get it will get it. And of course, since the messaging went up on about that, publish subscribe is when you post something to a node and everybody gets it. If you subscribe, you know everybody gets it free. Home is supposed to be instantly. Talk to you a little bit more about that soon. Multi is a chat. For example, if you sign up at java.org and participate in one of those conference rooms. Federation, you can connect to the various XMPP servers and you can talk to people on the XMPP servers using your XMPP server. First one of the mentoring is, for example, when you're using a game, you're searching songs in your music player and it instantly changes your music, what you're playing, across the network and you're probably going to say, that's an example of a personal mentor. So, that's all in the past. I want to talk a little bit about the future and what's actually going on right now. Any questions so far? So, I want to talk about publish subscribe first. It's getting a lot of press at the moment because we're realizing, especially in the road, that certain architectures brands this has really set up to be, for example, Twitter or, I mean, we need to use REST because it's pretty much very similar to Twitter and someone's press. So, we have to look into this and we've come across that publish subscribe is actually very well invested for us. So, what essentially happens is there's a node on an XMPP server and people will subscribe to that and at the moment somebody publishes something and everybody will get an application. So, in this case, Stanzo looks something like this. You have an IQ which is a rapid Stanzo from XMPP.org to Popsub server and then you create another Popsub element inside that sets the namespace and after that you specify which node you're publishing into. So, in this case, you're publishing into the Apple server and we're going to publish that and the moment you publish it, all the subscribers will get to the Apple server in their registry history. So, using publish subscribe we can do a lot of cool stuff. First, and something close to our art and interior is microblogging. We're actually using the first one that comes in for a call. So, the way we do microblogging is everybody who is registered presently has an account on an XMPP server and just like changing songs you can change your status and of course we persist the status of the back end and every time you change your status, everybody who is following you will instantly get an object including a cluster. So, that's what happens and you can also do real-time search. For example, if you move by Twitter, you can say, I want to let me create all updates and then Google or whatever search engine you subscribe to it every time they get any more updates, they'll push all updates more and Google and Yahoo or whoever wants the data will get it. You can also do real-time topic tracking so it's like RSS except, I mean, of course this would require some heavy players to actually set the feeds up but if you want to, you know, sort of as a return on phone you set up a, you want to track it somewhere and you can cross your phones and I am going to process this phone. You can also do collaborative editing. This is purely theoretical. I try to write it up but I got lazy and I couldn't even do it. So, using Popsup, you just have one great text boss, I'm just starting the years in the room, so you'll have one big text boss and everybody's connected to it. We'll make changes and these changes will be pushed out to Popsup and it'll just send out to everybody else and you can keep the documents in like that. Any questions about Popsup? I would also like to talk about real-time user interfaces. Has anyone here used presently? Beside me, I'm Brandon, my co-worker. Okay, so we recently updated it to be a lot more alive. Before it was just very unfolding. Now it uses XMPD to get the messages into your screen. So think of it 10 times more lightiness on your product screen. So we're doing that using something called Bosch, which I'm going to tell you a little bit more. But what I really want to get across is that JavaScript-based XMPD clients are really mature at the moment. And if you can, you should be using them to make your user interfaces really shine. You can jQuery and stroke which is what we're using in itself will almost be close to 100% of the time you're live if you use XMPD correctly. And the way to actually get these features in, I'm going to show you how to work with Ruby and XMPD on the back end. And on the front end, I'll show you how to connect it to your web server to the client's browser using JavaScript. So at the moment, presently, he's using Bosch user interfaces. Also, Graph.io has a full 100% real-time UI. Does anybody hear from Graph.io? You're from Graph.io? No? Okay. But have you seen their interface? Do you like it? Okay, he likes it. So let's talk a bit about the back end. There's only, in my opinion, only two good Ruby libraries for XMPD out there. The first one is XMPD or it's been around for a while. I think over maybe over three or four years. It's very full-featured. The bad news is there's almost documentation is non-existent. It took me a long time to gather what's coming up. And because of the threats you can't really, you can't really directly run it in a Rails app. You'll have to run external learning and connect to it using Rails and do whatever you can on it. I would recommend this for XMPD applications that don't have interface with Rails. Like Twitterspy. Twitterspy is the same. Twitterspy is an open source Ruby product where you can connect to it using a screenshot or whatever XMPD account. And you can say track this topic. And it will go to Twitter and post on it and send you a message. And the guy hasn't done any scaling work on it. So don't sign up because I'm on it. And if you sign up it'll make it slower for me. It's down right now anyway. So I'm going to sit and make codes on it. But that uses XMPD for R. We are looking for contributors for Stroke Ruby. This is the little top of Live Stroke which is a really good CXMPD library. We have most of the code ready. And it's connecting. We're using it in production. But it's not ready to release to the public. It's only a few years because we don't know how to write documentation. So if you can write documentation and can actually condense down really complex code into a very easy to use interface, you could use your help. I'm going to actually work on this a little bit and put up some documentation after the conference. So I'll post on Twitter about it. So the good news about Stroke Ruby is that you can actually run this within your application. You don't have to run it and run it from the game. You will have to connect to the XMPD server every time. Which adds a little bit of overhead but in the long run it doesn't really affect the response time as much. Of course if you're working on the back end of the XMPD, I recommend that you don't do any long running tasks within the Rails application. And you always set your time on, set your time on. So any questions about that? I suggest that you do if you're working with Ruby and XMPD, I suggest that you do most of the work on the front end. So I would highly recommend that you use a JavaScript base in XMPD client and use that in the client browser and make it receive XMPD messages so that you have a faster interface and you rail that as a native type. So the way to do this is to leverage a new protocol, sorry, that's protocol which stands for bi-directional streams over synchronous HTTP. First HTTP is a request response protocol that has the synchronous so it's not really easy to do long running streams with HTTP and those are the kinds that are required for XMPD connection. So an alternative to this is comment in here in the front. So if you're ever, I think, I'm not 100% sure, but if you were watching Mac owners live or one of those websites, one of them had a comic based push server so when you connected they were typing away updates from WWDC or something and you got them really quickly and that was the only website that survived any other one just went down. So comment requires a single persistent connection to the HTTP server but Bosch can survive over disconnects, you can survive over changing to multiple networks. It's pretty robust and it's full form HTTP request that are passed around between the client and the XMPD server so it goes through most processes. Prefile line starts at the client. The client will connect to a Bosch connection manager which will then forward the request to the XMPD server and most Neo-XMPD servers like EJF or D, there's actually a Bosch connection manager embedded within the server so you can have it run separately between whatever app. So the way that works is like this. There are two conditions. The client, every time that receives a message from the Bosch connection manager will have to return something and the same goes for the XMPD server. Every time for the connection manager, every time it receives something it has to return something. So let's say the client will say I don't want to authenticate and the server says authenticate and the client says here's the password and the client says I'm waiting for messages and the server has to return something but it can wait for a very long time. We use a long time request and the server will wait and say I don't have anything and send that to the client. It's like you say okay that's fine but I don't have anything. Now I'm waiting again and the server will wait for a while but to get something and send it to the client I will say I don't have anything and send it back. So there's a chain that goes on and it maintains for a very long time. And this is pretty much what about here. Are you understanding this or should I try again? You got it? Okay. So we use Bosch with JavaScript to write really responsive user interfaces. And we can do that using stroke which is written by Jack Moffitt. He has a very cool blog at metajac.im and he works for Chesspark. And then if you listen to the WooChess fan, the prisoner has WooChess.com I believe their Chesspark has been off. So stroke is using production presently at Chesspark and it's very, very awesome. I highly, highly recommend that you use stroke. And an example of a code. So first you see you can create a new connection. It maps to the slash HTTP client on your website. This will take you forward to the SMBP server. And you connect your user name and your password and you give it a handler function. So after that you can attach handlers for your SMBP stanza. So if you receive a message stanza like I showed before, then you can attach a handler so that it will call the onMessage function every time it gets a message stanza. And moving on, if you can also specify namespaces. So you can say any Pubsub event that is also a message should be handled by a onPubsub event function. This is very powerful. I'm only showing the three lines of code, but you get to the end of it and see what you can come up with. So how about 10 minutes. So I'd like to talk about presently a little bit and the games that we got from the solution to SMBP. Let me demo that. This is our presently application. Can you guys see that? This is internal. I'm using within a creative. I'm not showing anything sensitive. So at this point this is connected to the SMBP server. So we can start with the programs. If I send a message at this point it's posting to Rails. Rails will then forward the update to the SMBP server which will then send it back to the browser using Flash. And we are not making any requests from Rails at this point. All it's doing is posting the update to the Rails server and after that, Flash will take care of it. The SMBP server will forward a message and the functions that I have set up using Scrub will render the update very good. So that's pretty much the quick demo and then we get back to presentation. So this is the architecture we had before we switched to SMBP. We grew out of elements so we don't really want to optimize anything. So we had a regular browser and we had jQuery updates and it would constantly pull and it would get new updates. It's pretty much the most basic to our app. And then we had some problems with our servers getting higher. So we set up a custom index to get our updates and the servers had no response. And we also had these programs. And then we needed to scale because people started coming to the site and we were getting publicity. So then we moved to this architecture. So what happens is the client will only post to Rails. They will get the initial page and then the post to Rails on every update. And then Rails will forward to each average using Spark Ruby. And then of course we hook that to the client using Bosch. And they will send a notification to the client just as if the client is a regular message-in client. I'm sorry, just as if the browser is a regular message-in client. Any questions? Let us know. And it scales really, really well. Now we can even run the whole app on an assembly machine. And an assembly server on another machine and we still hold that very well for a very long time. But even if you have a thousand comments, it's still good. I think that's what I was supposed to do. So a little few words about assembly servers. Each average is written in Erlang. It's highly scalable, actively maintained. And if you know Erlang, it's very easy to hack. The XMTB server we are running at present free is EJVD and it's heavily customized for us. So don't try that at home. It also runs at chesspark. Java D2 is a rewrite of the original Java server. It's written in C. It is being actively maintained. And I think it's pretty fast and easily customizable. I heard people saying, talking about that. Tegacea is written in Java. It is actively maintained. The CeaseMe guys really love Tegacea. They have a video on YouTube. I'm sorry. So it's like a video conversation site. And they use XMTB Heaven. They really love Tegacea. OpenFire is written in Java. Actively maintained. Most enterprise on and off networks is open fire. They can figure out how to set up EJVD and open fire is the next best bet. It's a large community, lots of clients. And if you're writing basic XMTB apps, you just send messages back and forth and it's fine. You can use it. ProCity is brand new. I haven't looked at it at all. But I don't want to do it without the list. It's written in Gula. And the nickname is really likely in the store. If you guys have seen any of this, you should check that out. There are already solutions present for most of the common express problems. And a lot of those solutions are already specced up very terribly. The XMTB and the XMTB website and a lot of the servers do implement it. Of course, you're going to find some servers that don't implement certain features that you want and some do. But that's something that's just going to get better in time. If you guys have one contribute, it would be really awesome. Yeah, that's about it. So, any questions? That group would be, you know, the JavaScript as an XMTB platform. Most of the time, see, that's the thing. It's all about the road to the JavaScript. So, anything that's hosted presently will, if they're using the web browser, it will go to the JavaScript and get to the user. We have a JavaScript file back just in case that's in the server goes down and that doesn't happen yet. And one of the things that will happen is that it's pretty stable. As far as daily updates, we have over a million updates right now. And the traction goes up through the XMTB server and we haven't had so many new updates so far. What about on the JavaScript side? Like, on the client itself, I know. Like, EJRD skills really well. It might send a thousand messages to a JavaScript client. Well, of course, I mean, you have to account for that. We've proven updates, so it doesn't just add up to the bottom that they crash your browser. So, you have to be careful that your browser doesn't, you know, take a volume number and crash. So, even if you send a thousand updates at one time and you've tested this, all thousand will get to the browser. And unless the browser crashes, then, you know, you get it. Yes. Are you still using separate bots to talk to other Java servers or have you looked at them directly to EJRD? We're working on that. The gateway support in EJRD is very, very possible. But we have something in the works that's kind of floating in the minds. And it's going to actually affect all the Ruby guys as well. What we're doing is we're reporting the purple to Ruby. The purple is the series in ADM and game that's standing around it. So, anything that will run on ADM, I mean, that ADM can connect to it, or a game can connect to it, it will soon be able to connect to it. We're working on that ETA, I don't know. But most of it's done that you asked me. Any other questions? Purple Ruby. Do you mean about the actual? No, but I know they use it. That's about it. I haven't looked into it very in detail. What I know very, very is just XMPV and QP. But I understand it correctly. But I don't know exactly what I think. They use XMPV mostly for presence. Anybody for mentioning that here? Presently, when somebody signs in and catches from the database. So, whatever, you know, the history of discussion in the database, only new updates are sent to the connected clients. Because XMPV is... The Rails app. Yeah, the Rails app. Right, right. And I mean, we don't offload the saving of the update to a queue. So, we don't have problems that Twitter had, and one of their queues went down. We save everything directly. We're not Twitter or anything. It's a completely different problem today. So, we don't have to worry about saving our updates and something like that. Yeah. Are you using JEP16 PubSev to publish the... We're using it the right way for the approximate thing. We haven't had any problems so far. And PubSev is the way to go from, you know, to what I can tell. That's why it's scaling beautifully. It's not having any problems. And I think they're probably using PubSev for other projects, besides putting them into... sessions. Okay, we're done.