Unified Communications with Pàdé
Olajide, Dele
Pàdé (the "p" is pronounced explosively) is a new unified communications solution from the Ignite Real-time community that is built by integrating the SIP and HTTP protocols with XMPP and is focused at the enterprise desktop for small and medium sized businesses. It is implemented client-side as a web browser extension and server-side as a collection of supporting plugins that run inside the Openfire XMPP server. The purpose of the talk is to introduce Pàdé and show how the plugin architectures of Openfire, Chromium and Converse have provided a development ecosystem for creating business driven communication applications and solutions for enterprises. Pàdé is the Yoruba word for "Meet". It is a unified communications client for Openfire Meetings and uses the following front end web applications. Jitsi-Meet for SFU-based WebRTC audio/video conferencing, screen share and real-time application collaboration with Jitsi Video-bridge, SIP.js for SIP based telephony with FreeSWITCH, Converse.js for XMPP chat/groupchat with Openfire, Chat REST API for creating bots and enabling integration with business applications. This talk will first introduce Pàdé and then focus on how the plugin architecture of the Chromium web browser, ConverseJs and Openfire made it possible to quickly integrate HTTP and SIP with XMPP and create a feature-rich and very extensible unified communications solution for small and medium businesses.
 I'm going to get the doors closed and then you can start. I can start. Thank you. Good afternoon everyone. I bring you greetings from sunny Kent. It was snowing yesterday and I noticed it was sunny today. I live in Kent in the UK, south east England. I'm going to dedicate this presentation to a classmate of mine who passed away at the beginning of the week. His name is Afam. Thank you for coming out to listen to this presentation and this talk. You can all hear me. Excellent. This presentation is basically about the work I've been doing at Ignite Real Time on a new software project called Bade. It's a Yoruba name and when you pronounce P in the Yoruba language, it has to sound explosively. For instance, a Yoruba person will go, the P has to be explosive. It actually means meet or the verb of meeting. It's basically the name of a project that we've started at Ignite Real Time. What do we do at Ignite Real Time? XMPP. Let me try something right now. A quick show of hands. How many people know about Ignite Real Time? Wonderful. How many people use Open Fire? How many people use SMAC, the client API? I was expecting a lot more hands with SMAC. That's very popular with Android developers. How many people use Spark, the desktop client? Wow. I'm about to tell you about a new software project that's come out of Ignite. It's called Bade, as I've said. Basically, it's a unified communications client. Why is it unified? Communications? Basically, it combines not just XMPP, it combines SIP as well as XMPP, and even adds in, throws in email there. I'll tell you more in a minute. One of the things about what we do at Ignite Real Time is about delivering real-time communication solutions. I said just a few minutes ago, our main projects are Open Fire, which is an XMPP server. SMAC, the client XMPP client API, and then Spark, the XMPP desktop client, which was built with SMAC. One of the things that attracted me to XMPP about 15 years ago when I joined Ignite Real Time, at that point in time, I was working with BT as a system integrator, and we needed a real-time engine to route real-time messages in the telephone system. We ended up with XMPP, and by the time I left BT, we had actually integrated Open Fire into the main products in BT. As far as I can tell, I think it's still using XMPP to route messages. This is a system that BT uses in the finance community, and many of the major banks today are still using this system. Why am I excited about XMPP? It's the X in the XMPP. Another quick show of fans. I mean, people know about the program called X Factor on TV. Really? Wow, it's very popular in the UK. I think XMPP has got the X Factor. Do you know why? Because it's got that X, and that X is not just about being extensible. I think it's exotic. I think it's explosive. I think it's experimental. I think it's exciting, exhilarating. You want me to say some more X's? And it's that X path that really attracted me, because we could do a lot more than just the basic messaging and presence. And actually, to prove that point, is actually why I got involved in developing this, got involved in the development of this new project called Paddy. Now, what does it do? Now, before I can explain to you what it does, what I do in my daytime job is I'm a real-time collaboration consultant. I talk with small and medium businesses, and basically I advise them on their real communication needs in terms of their solutions and things they need to do. When I used to be in BT, my job title was a system integrator. You probably have had that fancy term. It really means a jack of all trade, my stuff, nothing specific. Basically, I did everything, but it was really mostly integration. So what drives me is to be able to not write code from scratch, but to take something someone else has done, especially software components, bring them together and turn them into a symphony. Sometimes I get lucky. I work with smart software that can actually become self-aware and start improvising. And guess what I get when I join them together? A jazz band. So one of the things I find exciting being at Ignite is that there's such a load of stuff and a wealth of assets and things that you can put together to deliver some really good solutions. So as a consultant, when I talk to customers and ask them, what is it that you want to be able to achieve with your real-time communications? And this is the kind of picture that they painted to me. So they have employees and staff walking in teams, and those people walking in teams, they want them to be able to walk and deliver, sorry, support their external customers and clients. So the first thing they want to do is to be able to push out real-time messages to these customers and clients. And so therefore they want to do message broadcasting. They want to be able to send out blogs and stuff like that. And also they want to create a community around their customers and clients based around the products and services they offer. And they also want to have people within that user community become ambassadors for their products and their services. So they want these people to sell their products on their behalf because these people get very passionate about things. And if you've ever been in a community where you find someone so passionate about a new bed and yet he doesn't work for that company, he just likes the bed and he's willing to tell everybody. Now customers want to take advantage of what those people can do to their products and services, so they want to create communities where those people can be, they can keep the communities thriving for them. Now at the same time, they want their customers and clients to be able to come in the opposite direction as in communicate back to them through their websites and actually get hold of the right person at the right time to solve the particular problem that that particular customer or client may have. And as you probably noticed, quite a number of websites are now having that little bubble on the bottom right hand side in which you click on the button and you can get hold of someone except that for most sites that I have been to, it's nobody's available, leave a message, we'll get back to you. Doesn't that remind you of voicemail Oliver again? So really what they want is real time. So you go to the customer's website, you go to something like that and you can get hold of the person that you really need to get hold of. Now to be able to do that, the teams within the organizations have to be able to walk together better. So in other words, they have tools that allow them to walk in groups, group chat, be able to drop out, break out of those persistent conversations into meetings, most of the companies are supported by suppliers and external partners and they want those partners and external suppliers to be on demand, to be on standby because they're trusted. They don't want them to come in through the external network, but they want them to come through a trusted network beyond standby and they can drop them straight away into conversations. So that's the landscape of the requirements that I picked up over the few years that I've been a consultant doing this. And to solve that problem, I put together a solution based on what we have at Ignite real time. You all know OpenFire, well, from a show of hands, not everyone knows OpenFire, but basically it's an XMPP server. I really don't have time to go through the basic details of what's happening in here other than to tell you that one of the beauties of what we have at Ignite with OpenFire is that it's a plug-in architecture. You've got, just like XMPP being extendable, we have the basic server doing the core XMPP stuff and then you can write a plug-in to extend it. Now, this is the thing about plug-ins that I found working with OpenFire. So I generally end up with plug-ins in three types. So you have plug-ins that you write that extend the protocol itself. Now, in XMPP, when you extend the protocol, we call it an EXEP. And you can extend the protocol like that. And now a good example of that is the fact that we were able to implement a very early version of WebSockets in OpenFire. And the reason because of that is that OpenFire has a Jetty web server built-in. And Jetty actually provided an experimental version of WebSockets quite a while back, even before it became a standard. It was so easy to write a plug-in that turned WebSockets into an additional channel for OpenFire. Then later on, when it became a standard, someone in the community then turned that plug-in into the standard. And then after that plug-in settled down and became mature, who's the lead developer for OpenFire, then brought it into the core product. Right, so that brings me to the front end. So in doing the front end, I actually, it's an interesting story that I went through in order to do the front end. I told you that we have SMAC, the client library, and we have SPAC, the desktop client. So when I started out trying to build, per day, the client, I knew I had to do two things. One, I wanted the user experience to be like what people were used to with SPAC in order to meet the requirements I had shown you earlier on. And then two, I needed the front end to be very modern. It had to be HTML. So my first reaction was, okay, we'll build the client, reusing all the stuff from SMAC or the stuff from SPAC, but we'll give it an HTML front end. And then I came across an interesting project called JX Browser, but unfortunately I couldn't go far and do anything with that. I'll come to that in a minute. So I couldn't do anything much with that. So the next thing I thought was, okay, I'll use, there was a project called CEF, and that's Chrome Embedded Framework. Has anyone used that where you take Chrome and embed, oh, there you go, you take Chrome and you embed it into your own apps? So it comes, it's basically C code, but there's also a Java version of it called Java CEF. The problem with that is that I would have to build my distributables, and I would have to build it for Linux, I have to build it for PCs, for Windows, and I have to build it for Mac. So again, not a good solution. And then that brought me to Electron. How do people build here, build their applications with Electron? The problem of distributables, the runtime libraries, the Electron runtime, were solved with Electron because you can just pick them up and put it into your build. But I still had the problem that I would have to write all the business logic all over again. I won't be able to take advantage of the code I wanted to take to reuse from SMAC and SPAC. In the end, I ended up with using a Chrome extension. Now, how many people have here developed with Chrome extensions or browser extensions? Because it's now a standard. When I started out, it was just called Chrome extensions because it was only Google doing it, but now it's now become a standard. I mean, people have... Well, I bet you don't know that they behave like desktop applications. They actually treat Chrome like a runtime engine. So you can write your Chrome extension, it starts up automatically like a desktop application where you start your operating system. Two, it runs in a very privileged mode. It's not like a regular web page. It has super privileges and it's more secure. So you don't have the problem of cross-domain contamination that you have with web pages. You've got... I do music, for example, so you have access to MIDI and stuff like that. And so I develop by using that. I'm sure you know what you want to see what it looks like, don't you? Yeah. I haven't got time to show you a demo. And I haven't got time to go through all the features, so that's why I put that up there. But I'll try and quickly go through four features identified. So this is what it looks like. JC was very gracious to mention that it uses Converse. So as far as the messaging side of things, I've integrated Converse in there. And it's not just dropping it in. Converse and JC Meet and the SIP client are all homed in on the same user. So back in OpenFire, there was an OpenFire plugin that does the mapping between the SIP identity and the XMPV identity. So it's the same user identity that you use in Converse that you're also using JC Meet. And then that you're also using the SIP client. And then you have... So that's JC Meet down there and then you have a SIP phone. So in a corporate environment, that means you can take all your phone calls using that as your front end. That's why it's a unified client. It also means you can do all your messaging, chat, group chat, and then broadcast. So how do people use WhatsApp here? So in WhatsApp, you use your normal chat. Yes, you do group chat. How do you use the broadcast part of it? Now, it's a very popular business in the finance community. Basically, you send out one message to a group, but what comes back are individual replies. They use it a lot in business. And then the nice thing I'm very happy about, and this is the glue part. That's the part that I really do, is that I put a configuration app in there. So which means all the parameters in JC Meet that you have to normally code in the config, all the parameters in Converse.js that you have to code into your config are now visible, just like in OpenFire. You've got a web interface in front of all those parameters, and you can change them right there on the client. So what does the party version of Converse look like? It's the same thing, isn't it? Basically, it looks like that, but this is the exciting part. Basically, it looks like that, but because of what JC Brand did with Converse, giving it the plugin architecture means we can extend it. And one of the things I've done in my days to write loads of plugins that extend it. So you've got plugins that extend the slash commands. So you've got slash commands. You can start JC Meet with a slash command. You can search for people. You can use the full text search. OpenFire has a loose end full text search engine. You can search for words, keywords like that, and pops it up. Okay, so let me go through my full use cases for you. I wanted to show you. The first one is auto registration. So I'm involved at the moment in trying to create a community for the Yoruba people. So I've created a version of Paday. Now, the nice thing about Paday is that it's generic and it's brandable. You can just take it. Brand it, change the logos, change everything so easily and create your own version of it. You can take all the config parameters, take out what you need, add what you need. So that's a customized version for this community. It doesn't have any connection details. That's because the server name, the domain name and all that is baked into the app. You just go to the web store, install it, and all you do is enter your name. But the one thing I wanted it to have is auto registration. Now, normal XMPP registration suffers a lot from spamming. And that's because we can't verify the identity of the person at the other end. And the solution to that is to use email. Now, because Paday has an email built in, in other words, your identity, XMPP.
 I'm going to get the doors closed and then you can start.  I can start. Thank you.  Good afternoon everyone.  I bring you greetings from sunny Kent. It was snowing yesterday and I noticed it was sunny today.  I live in Kent in the UK, south east England.  I'm going to dedicate this presentation to a classmate of mine who passed away at the beginning of the week. His name is Afam.  Thank you for coming out to listen to this presentation and this talk.  You can all hear me. Excellent.  This presentation is basically about the work I've been doing at Ignite Real Time on a new software project called Bade.  It's a Yoruba name and when you pronounce P in the Yoruba language, it has to sound explosively.  For instance, a Yoruba person will go, the P has to be explosive.  It actually means meet or the verb of meeting.  It's basically the name of a project that we've started at Ignite Real Time.  What do we do at Ignite Real Time?  XMPP. Let me try something right now.  A quick show of hands. How many people know about Ignite Real Time?  Wonderful. How many people use Open Fire?  How many people use SMAC, the client API?  I was expecting a lot more hands with SMAC. That's very popular with Android developers.  How many people use Spark, the desktop client?  Wow. I'm about to tell you about a new software project that's come out of Ignite.  It's called Bade, as I've said.  Basically, it's a unified communications client.  Why is it unified? Communications?  Basically, it combines not just XMPP, it combines SIP as well as XMPP,  and even adds in, throws in email there.  I'll tell you more in a minute.  One of the things about what we do at Ignite Real Time  is about delivering real-time communication solutions.  I said just a few minutes ago, our main projects are Open Fire,  which is an XMPP server.  SMAC, the client XMPP client API,  and then Spark, the XMPP desktop client, which was built with SMAC.  One of the things that attracted me to XMPP about 15 years ago  when I joined Ignite Real Time,  at that point in time, I was working with BT as a system integrator,  and we needed a real-time engine to route real-time messages in the telephone system.  We ended up with XMPP, and by the time I left BT,  we had actually integrated Open Fire into the main products in BT.  As far as I can tell, I think it's still using XMPP to route messages.  This is a system that BT uses in the finance community,  and many of the major banks today are still using this system.  Why am I excited about XMPP?  It's the X in the XMPP.  Another quick show of fans.  I mean, people know about the program called X Factor on TV.  Really? Wow, it's very popular in the UK.  I think XMPP has got the X Factor.  Do you know why?  Because it's got that X, and that X is not just about being extensible.  I think it's exotic.  I think it's explosive.  I think it's experimental.  I think it's exciting, exhilarating.  You want me to say some more X's?  And it's that X path that really attracted me,  because we could do a lot more than just the basic messaging and presence.  And actually, to prove that point,  is actually why I got involved in developing this,  got involved in the development of this new project called Paddy.  Now, what does it do?  Now, before I can explain to you what it does,  what I do in my daytime job is I'm a real-time collaboration consultant.  I talk with small and medium businesses,  and basically I advise them on their real communication needs  in terms of their solutions and things they need to do.  When I used to be in BT, my job title was a system integrator.  You probably have had that fancy term.  It really means a jack of all trade, my stuff, nothing specific.  Basically, I did everything, but it was really mostly integration.  So what drives me is to be able to not write code from scratch,  but to take something someone else has done,  especially software components,  bring them together and turn them into a symphony.  Sometimes I get lucky.  I work with smart software that can actually become self-aware  and start improvising.  And guess what I get when I join them together?  A jazz band.  So one of the things I find exciting being at Ignite  is that there's such a load of stuff and a wealth of assets  and things that you can put together to deliver some really good solutions.  So as a consultant, when I talk to customers and ask them,  what is it that you want to be able to achieve with your real-time communications?  And this is the kind of picture that they painted to me.  So they have employees and staff walking in teams,  and those people walking in teams,  they want them to be able to walk and deliver,  sorry, support their external customers and clients.  So the first thing they want to do is to be able to push out real-time messages  to these customers and clients.  And so therefore they want to do message broadcasting.  They want to be able to send out blogs and stuff like that.  And also they want to create a community around their customers and clients  based around the products and services they offer.  And they also want to have people within that user community  become ambassadors for their products and their services.  So they want these people to sell their products on their behalf  because these people get very passionate about things.  And if you've ever been in a community where you find someone so passionate  about a new bed and yet he doesn't work for that company,  he just likes the bed and he's willing to tell everybody.  Now customers want to take advantage of what those people can do to their products and services,  so they want to create communities where those people can be,  they can keep the communities thriving for them.  Now at the same time, they want their customers and clients to be able to come  in the opposite direction as in communicate back to them through their websites  and actually get hold of the right person at the right time to solve the particular problem  that that particular customer or client may have.  And as you probably noticed, quite a number of websites are now having that little bubble  on the bottom right hand side in which you click on the button  and you can get hold of someone except that for most sites that I have been to,  it's nobody's available, leave a message, we'll get back to you.  Doesn't that remind you of voicemail Oliver again?  So really what they want is real time.  So you go to the customer's website, you go to something like that and you can get hold  of the person that you really need to get hold of.  Now to be able to do that, the teams within the organizations have to be able to walk together better.  So in other words, they have tools that allow them to walk in groups, group chat,  be able to drop out, break out of those persistent conversations into meetings,  most of the companies are supported by suppliers and external partners  and they want those partners and external suppliers to be on demand, to be on standby  because they're trusted.  They don't want them to come in through the external network,  but they want them to come through a trusted network beyond standby  and they can drop them straight away into conversations.  So that's the landscape of the requirements that I picked up over the few years  that I've been a consultant doing this.  And to solve that problem, I put together a solution based on what we have at Ignite real time.  You all know OpenFire, well, from a show of hands, not everyone knows OpenFire,  but basically it's an XMPP server.  I really don't have time to go through the basic details of what's happening in here  other than to tell you that one of the beauties of what we have at Ignite with OpenFire  is that it's a plug-in architecture.  You've got, just like XMPP being extendable, we have the basic server doing the core XMPP stuff  and then you can write a plug-in to extend it.  Now, this is the thing about plug-ins that I found working with OpenFire.  So I generally end up with plug-ins in three types.  So you have plug-ins that you write that extend the protocol itself.  Now, in XMPP, when you extend the protocol, we call it an EXEP.  And you can extend the protocol like that.  And now a good example of that is the fact that we were able to implement a very early version of WebSockets in OpenFire.  And the reason because of that is that OpenFire has a Jetty web server built-in.  And Jetty actually provided an experimental version of WebSockets quite a while back,  even before it became a standard.  It was so easy to write a plug-in that turned WebSockets into an additional channel for OpenFire.  Then later on, when it became a standard, someone in the community then turned that plug-in into the standard.  And then after that plug-in settled down and became mature,  who's the lead developer for OpenFire, then brought it into the core product.  Right, so that brings me to the front end.  So in doing the front end, I actually, it's an interesting story that I went through in order to do the front end.  I told you that we have SMAC, the client library, and we have SPAC, the desktop client.  So when I started out trying to build, per day, the client, I knew I had to do two things.  One, I wanted the user experience to be like what people were used to with SPAC  in order to meet the requirements I had shown you earlier on.  And then two, I needed the front end to be very modern.  It had to be HTML.  So my first reaction was, okay, we'll build the client,  reusing all the stuff from SMAC or the stuff from SPAC, but we'll give it an HTML front end.  And then I came across an interesting project called JX Browser,  but unfortunately I couldn't go far and do anything with that.  I'll come to that in a minute.  So I couldn't do anything much with that.  So the next thing I thought was, okay, I'll use, there was a project called CEF,  and that's Chrome Embedded Framework.  Has anyone used that where you take Chrome and embed, oh, there you go,  you take Chrome and you embed it into your own apps?  So it comes, it's basically C code, but there's also a Java version of it called Java CEF.  The problem with that is that I would have to build my distributables,  and I would have to build it for Linux, I have to build it for PCs, for Windows,  and I have to build it for Mac.  So again, not a good solution.  And then that brought me to Electron.  How do people build here, build their applications with Electron?  The problem of distributables, the runtime libraries, the Electron runtime,  were solved with Electron because you can just pick them up and put it into your build.  But I still had the problem that I would have to write all the business logic all over again.  I won't be able to take advantage of the code I wanted to take to reuse from SMAC and SPAC.  In the end, I ended up with using a Chrome extension.  Now, how many people have here developed with Chrome extensions or browser extensions?  Because it's now a standard.  When I started out, it was just called Chrome extensions because it was only Google doing it,  but now it's now become a standard.  I mean, people have...  Well, I bet you don't know that they behave like desktop applications.  They actually treat Chrome like a runtime engine.  So you can write your Chrome extension, it starts up automatically like a desktop application  where you start your operating system.  Two, it runs in a very privileged mode.  It's not like a regular web page.  It has super privileges and it's more secure.  So you don't have the problem of cross-domain contamination that you have with web pages.  You've got...  I do music, for example, so you have access to MIDI and stuff like that.  And so I develop by using that.  I'm sure you know what you want to see what it looks like, don't you?  Yeah.  I haven't got time to show you a demo.  And I haven't got time to go through all the features, so that's why I put that up there.  But I'll try and quickly go through four features identified.  So this is what it looks like.  JC was very gracious to mention that it uses Converse.  So as far as the messaging side of things, I've integrated Converse in there.  And it's not just dropping it in.  Converse and JC Meet and the SIP client are all homed in on the same user.  So back in OpenFire, there was an OpenFire plugin that does the mapping between the SIP identity and the XMPV identity.  So it's the same user identity that you use in Converse that you're also using JC Meet.  And then that you're also using the SIP client.  And then you have...  So that's JC Meet down there and then you have a SIP phone.  So in a corporate environment, that means you can take all your phone calls using that as your front end.  That's why it's a unified client.  It also means you can do all your messaging, chat, group chat, and then broadcast.  So how do people use WhatsApp here?  So in WhatsApp, you use your normal chat.  Yes, you do group chat.  How do you use the broadcast part of it?  Now, it's a very popular business in the finance community.  Basically, you send out one message to a group, but what comes back are individual replies.  They use it a lot in business.  And then the nice thing I'm very happy about, and this is the glue part.  That's the part that I really do, is that I put a configuration app in there.  So which means all the parameters in JC Meet that you have to normally code in the config,  all the parameters in Converse.js that you have to code into your config are now visible,  just like in OpenFire.  You've got a web interface in front of all those parameters,  and you can change them right there on the client.  So what does the party version of Converse look like?  It's the same thing, isn't it?  Basically, it looks like that, but this is the exciting part.  Basically, it looks like that, but because of what JC Brand did with Converse,  giving it the plugin architecture means we can extend it.  And one of the things I've done in my days to write loads of plugins that extend it.  So you've got plugins that extend the slash commands.  So you've got slash commands.  You can start JC Meet with a slash command.  You can search for people.  You can use the full text search.  OpenFire has a loose end full text search engine.  You can search for words, keywords like that, and pops it up.  Okay, so let me go through my full use cases for you.  I wanted to show you.  The first one is auto registration.  So I'm involved at the moment in trying to create a community for the Yoruba people.  So I've created a version of Paday.  Now, the nice thing about Paday is that it's generic and it's brandable.  You can just take it.  Brand it, change the logos, change everything so easily and create your own version of it.  You can take all the config parameters, take out what you need, add what you need.  So that's a customized version for this community.  It doesn't have any connection details.  That's because the server name, the domain name and all that is baked into the app.  You just go to the web store, install it, and all you do is enter your name.  But the one thing I wanted it to have is auto registration.  Now, normal XMPP registration suffers a lot from spamming.  And that's because we can't verify the identity of the person at the other end.  And the solution to that is to use email.  Now, because Paday has an email built in, in other words, your identity, XMPP.
Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_0_167.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_168_2591.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_2592_2843.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_2844_3191.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_3192_3767.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_3768_3815.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_3816_5147.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_5148_7787.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_7788_16343.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_16344_18983.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_18984_20483.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_20484_24491.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_24492_24539.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_24540_26543.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_26544_27263.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_27264_27311.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_27312_27659.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_27660_28475.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_28476_28547.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_28548_28595.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_28596_28643.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_28644_28691.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_28692_28739.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_28740_30131.png Unified_Communications_with_Pade_Making_the_X_in_XMPP_work_with_software_30132_30250.png
I'm going to get the doors closed and then you can start. I can start. Thank you. Good afternoon everyone. I bring you greetings from sunny Kent. It was snowing yesterday and I noticed it was sunny today. I live in Kent in the UK, south east England. I'm going to dedicate this presentation to a classmate of mine who passed away at the beginning of the week. His name is Afam. Thank you for coming out to listen to this presentation and this talk. You can all hear me. Excellent. This presentation is basically about the work I've been doing at Ignite Real Time on a new software project called Bade. It's a Yoruba name and when you pronounce P in the Yoruba language, it has to sound explosively. For instance, a Yoruba person will go, the P has to be explosive. It actually means meet or the verb of meeting. It's basically the name of a project that we've started at Ignite Real Time. What do we do at Ignite Real Time? XMPP. Let me try something right now. A quick show of hands. How many people know about Ignite Real Time? Wonderful. How many people use Open Fire? How many people use SMAC, the client API? I was expecting a lot more hands with SMAC. That's very popular with Android developers. How many people use Spark, the desktop client? Wow. I'm about to tell you about a new software project that's come out of Ignite. It's called Bade, as I've said. Basically, it's a unified communications client. Why is it unified? Communications? Basically, it combines not just XMPP, it combines SIP as well as XMPP, and even adds in, throws in email there. I'll tell you more in a minute. One of the things about what we do at Ignite Real Time is about delivering real-time communication solutions. I said just a few minutes ago, our main projects are Open Fire, which is an XMPP server. SMAC, the client XMPP client API, and then Spark, the XMPP desktop client, which was built with SMAC. One of the things that attracted me to XMPP about 15 years ago when I joined Ignite Real Time, at that point in time, I was working with BT as a system integrator, and we needed a real-time engine to route real-time messages in the telephone system. We ended up with XMPP, and by the time I left BT, we had actually integrated Open Fire into the main products in BT. As far as I can tell, I think it's still using XMPP to route messages. This is a system that BT uses in the finance community, and many of the major banks today are still using this system. Why am I excited about XMPP? It's the X in the XMPP. Another quick show of fans. I mean, people know about the program called X Factor on TV. Really? Wow, it's very popular in the UK. I think XMPP has got the X Factor. Do you know why? Because it's got that X, and that X is not just about being extensible. I think it's exotic. I think it's explosive. I think it's experimental. I think it's exciting, exhilarating. You want me to say some more X's? And it's that X path that really attracted me, because we could do a lot more than just the basic messaging and presence. And actually, to prove that point, is actually why I got involved in developing this, got involved in the development of this new project called Paddy. Now, what does it do? Now, before I can explain to you what it does, what I do in my daytime job is I'm a real-time collaboration consultant. I talk with small and medium businesses, and basically I advise them on their real communication needs in terms of their solutions and things they need to do. When I used to be in BT, my job title was a system integrator. You probably have had that fancy term. It really means a jack of all trade, my stuff, nothing specific. Basically, I did everything, but it was really mostly integration. So what drives me is to be able to not write code from scratch, but to take something someone else has done, especially software components, bring them together and turn them into a symphony. Sometimes I get lucky. I work with smart software that can actually become self-aware and start improvising. And guess what I get when I join them together? A jazz band. So one of the things I find exciting being at Ignite is that there's such a load of stuff and a wealth of assets and things that you can put together to deliver some really good solutions. So as a consultant, when I talk to customers and ask them, what is it that you want to be able to achieve with your real-time communications? And this is the kind of picture that they painted to me. So they have employees and staff walking in teams, and those people walking in teams, they want them to be able to walk and deliver, sorry, support their external customers and clients. So the first thing they want to do is to be able to push out real-time messages to these customers and clients. And so therefore they want to do message broadcasting. They want to be able to send out blogs and stuff like that. And also they want to create a community around their customers and clients based around the products and services they offer. And they also want to have people within that user community become ambassadors for their products and their services. So they want these people to sell their products on their behalf because these people get very passionate about things. And if you've ever been in a community where you find someone so passionate about a new bed and yet he doesn't work for that company, he just likes the bed and he's willing to tell everybody. Now customers want to take advantage of what those people can do to their products and services, so they want to create communities where those people can be, they can keep the communities thriving for them. Now at the same time, they want their customers and clients to be able to come in the opposite direction as in communicate back to them through their websites and actually get hold of the right person at the right time to solve the particular problem that that particular customer or client may have. And as you probably noticed, quite a number of websites are now having that little bubble on the bottom right hand side in which you click on the button and you can get hold of someone except that for most sites that I have been to, it's nobody's available, leave a message, we'll get back to you. Doesn't that remind you of voicemail Oliver again? So really what they want is real time. So you go to the customer's website, you go to something like that and you can get hold of the person that you really need to get hold of. Now to be able to do that, the teams within the organizations have to be able to walk together better. So in other words, they have tools that allow them to walk in groups, group chat, be able to drop out, break out of those persistent conversations into meetings, most of the companies are supported by suppliers and external partners and they want those partners and external suppliers to be on demand, to be on standby because they're trusted. They don't want them to come in through the external network, but they want them to come through a trusted network beyond standby and they can drop them straight away into conversations. So that's the landscape of the requirements that I picked up over the few years that I've been a consultant doing this. And to solve that problem, I put together a solution based on what we have at Ignite real time. You all know OpenFire, well, from a show of hands, not everyone knows OpenFire, but basically it's an XMPP server. I really don't have time to go through the basic details of what's happening in here other than to tell you that one of the beauties of what we have at Ignite with OpenFire is that it's a plug-in architecture. You've got, just like XMPP being extendable, we have the basic server doing the core XMPP stuff and then you can write a plug-in to extend it. Now, this is the thing about plug-ins that I found working with OpenFire. So I generally end up with plug-ins in three types. So you have plug-ins that you write that extend the protocol itself. Now, in XMPP, when you extend the protocol, we call it an EXEP. And you can extend the protocol like that. And now a good example of that is the fact that we were able to implement a very early version of WebSockets in OpenFire. And the reason because of that is that OpenFire has a Jetty web server built-in. And Jetty actually provided an experimental version of WebSockets quite a while back, even before it became a standard. It was so easy to write a plug-in that turned WebSockets into an additional channel for OpenFire. Then later on, when it became a standard, someone in the community then turned that plug-in into the standard. And then after that plug-in settled down and became mature, who's the lead developer for OpenFire, then brought it into the core product. Right, so that brings me to the front end. So in doing the front end, I actually, it's an interesting story that I went through in order to do the front end. I told you that we have SMAC, the client library, and we have SPAC, the desktop client. So when I started out trying to build, per day, the client, I knew I had to do two things. One, I wanted the user experience to be like what people were used to with SPAC in order to meet the requirements I had shown you earlier on. And then two, I needed the front end to be very modern. It had to be HTML. So my first reaction was, okay, we'll build the client, reusing all the stuff from SMAC or the stuff from SPAC, but we'll give it an HTML front end. And then I came across an interesting project called JX Browser, but unfortunately I couldn't go far and do anything with that. I'll come to that in a minute. So I couldn't do anything much with that. So the next thing I thought was, okay, I'll use, there was a project called CEF, and that's Chrome Embedded Framework. Has anyone used that where you take Chrome and embed, oh, there you go, you take Chrome and you embed it into your own apps? So it comes, it's basically C code, but there's also a Java version of it called Java CEF. The problem with that is that I would have to build my distributables, and I would have to build it for Linux, I have to build it for PCs, for Windows, and I have to build it for Mac. So again, not a good solution. And then that brought me to Electron. How do people build here, build their applications with Electron? The problem of distributables, the runtime libraries, the Electron runtime, were solved with Electron because you can just pick them up and put it into your build. But I still had the problem that I would have to write all the business logic all over again. I won't be able to take advantage of the code I wanted to take to reuse from SMAC and SPAC. In the end, I ended up with using a Chrome extension. Now, how many people have here developed with Chrome extensions or browser extensions? Because it's now a standard. When I started out, it was just called Chrome extensions because it was only Google doing it, but now it's now become a standard. I mean, people have... Well, I bet you don't know that they behave like desktop applications. They actually treat Chrome like a runtime engine. So you can write your Chrome extension, it starts up automatically like a desktop application where you start your operating system. Two, it runs in a very privileged mode. It's not like a regular web page. It has super privileges and it's more secure. So you don't have the problem of cross-domain contamination that you have with web pages. You've got... I do music, for example, so you have access to MIDI and stuff like that. And so I develop by using that. I'm sure you know what you want to see what it looks like, don't you? Yeah. I haven't got time to show you a demo. And I haven't got time to go through all the features, so that's why I put that up there. But I'll try and quickly go through four features identified. So this is what it looks like. JC was very gracious to mention that it uses Converse. So as far as the messaging side of things, I've integrated Converse in there. And it's not just dropping it in. Converse and JC Meet and the SIP client are all homed in on the same user. So back in OpenFire, there was an OpenFire plugin that does the mapping between the SIP identity and the XMPV identity. So it's the same user identity that you use in Converse that you're also using JC Meet. And then that you're also using the SIP client. And then you have... So that's JC Meet down there and then you have a SIP phone. So in a corporate environment, that means you can take all your phone calls using that as your front end. That's why it's a unified client. It also means you can do all your messaging, chat, group chat, and then broadcast. So how do people use WhatsApp here? So in WhatsApp, you use your normal chat. Yes, you do group chat. How do you use the broadcast part of it? Now, it's a very popular business in the finance community. Basically, you send out one message to a group, but what comes back are individual replies. They use it a lot in business. And then the nice thing I'm very happy about, and this is the glue part. That's the part that I really do, is that I put a configuration app in there. So which means all the parameters in JC Meet that you have to normally code in the config, all the parameters in Converse.js that you have to code into your config are now visible, just like in OpenFire. You've got a web interface in front of all those parameters, and you can change them right there on the client. So what does the party version of Converse look like? It's the same thing, isn't it? Basically, it looks like that, but this is the exciting part. Basically, it looks like that, but because of what JC Brand did with Converse, giving it the plugin architecture means we can extend it. And one of the things I've done in my days to write loads of plugins that extend it. So you've got plugins that extend the slash commands. So you've got slash commands. You can start JC Meet with a slash command. You can search for people. You can use the full text search. OpenFire has a loose end full text search engine. You can search for words, keywords like that, and pops it up. Okay, so let me go through my full use cases for you. I wanted to show you. The first one is auto registration. So I'm involved at the moment in trying to create a community for the Yoruba people. So I've created a version of Paday. Now, the nice thing about Paday is that it's generic and it's brandable. You can just take it. Brand it, change the logos, change everything so easily and create your own version of it. You can take all the config parameters, take out what you need, add what you need. So that's a customized version for this community. It doesn't have any connection details. That's because the server name, the domain name and all that is baked into the app. You just go to the web store, install it, and all you do is enter your name. But the one thing I wanted it to have is auto registration. Now, normal XMPP registration suffers a lot from spamming. And that's because we can't verify the identity of the person at the other end. And the solution to that is to use email. Now, because Paday has an email built in, in other words, your identity, XMPP.
I've been doing at Ignite Real Time on a new unified communications client. Why is it unified? real-time communication solutions. I said just a which is an XMPP server. SMAC, the client XMPP client API, and then Spark, the XMPP desktop client, which was built with SMAC. One of the in time, I was working with BT as a system We ended up with XMPP, and by the time I left BT, This is a system that BT uses in the finance is I'm a real-time collaboration consultant. I talk with small and medium businesses, and from a show of hands, not everyone knows you have plug-ins that you write that extend the the front end to be very modern. It had to be ended up with using a Chrome extension. Now, how cross-domain contamination that you have with web dropping it in. Converse and JC Meet and the SIP popular business in the finance community. giving it the plugin architecture means we can The first one is auto registration. So I'm involved at the moment in trying to create a community for the Yoruba people. So I've created solution to that is to use email. Now, because