We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

XMPP: get your shopping cart ready!

00:00

Formal Metadata

Title
XMPP: get your shopping cart ready!
Subtitle
Your guide through the candy store of XMPP extensions
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The eXtensibility of XMPP makes it extremely powerful. But it is easy to get lost in the supermarket of extensions. In this talk I will guide you though the extensions: how to read the labels? How to cook some common recipes? I will also show some exotic but nice ingredients. And last but not least: we will be having some protocol-fun! The eXtensible Messaging and Presence Protocol, XMPP, has extensibility at its core. It is because of the extensibility that there is a vivid XMPP ecosystem: it is easy to adapt XMPP to new developments and to new use cases. The XMPP Standards Foundation maintains a list of extensions to XMPP. In this talk I will dive into this list of extensions: what kind of extensions are there? What statuses can an extension have? What extensions to use in some common use cases? And I will touch some exotic extensions for use cases you may never have thought about. Oh, and what is the story about these ‘humorous’ extensions, can a protocol be humorous?
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
Kummer-TheorieDecision tree learningSoftwareGoodness of fitService (economics)Right angleComputer animation
Communications protocolKummer-TheorieCore dumpField extensionFunctional (mathematics)BitCore dumpComputer animation
Stack (abstract data type)Complex (psychology)UnicodeFunctional (mathematics)CASE <Informatik>BitComputer animation
Standard deviationCommunications protocolCore dumpKummer-TheorieInternet der DingeFreewareKummer-TheorieStandard deviationCommunications protocolSet (mathematics)Internet der DingeCore dumpComputer animation
Standard deviationProcess (computing)Field extensionLine (geometry)Kummer-TheorieFlow separationMathematicsStandard deviationLevel (video gaming)ImplementationEmailProcess (computing)Communications protocolComputer animation
Procedural programmingOnline chatProof theorySuite (music)Electronic mailing listCore dumpServer (computing)Client (computing)Instant MessagingMobile WebStandard deviationReal numberDifferent (Kate Ryan album)Field extensionLibrary (computing)Client (computing)Electronic mailing listCore dumpProcedural programmingFunctional (mathematics)Flow separationCommunications protocolTheory of relativityMereologyService (economics)Bit
SoftwareServer (computing)Client (computing)Computer wormField extensionPlug-in (computing)Data structureAdditionWebsiteClient (computing)Computer architectureMobile appFunctional (mathematics)NamespaceData storage deviceComputer animation
Communications protocolEuclidean vectorInductive reasoningServer (computing)Real numberMusical ensembleHeat transferInformation securityBinary fileSuite (music)Software developerRepresentation (politics)InformationData structurePresentation of a groupClient (computing)Message passingBinary codeDifferent (Kate Ryan album)Type theoryReal-time operating systemFrequencyWebsiteElectronic mailing listComputer programmingGame theoryPoint (geometry)Multiplication signSuite (music)Portable communications deviceLine (geometry)MereologyCollaborationismLatent heatGroup actionPersonal digital assistantConnectivity (graph theory)Communications protocolTelecommunicationEmailCASE <Informatik>Server (computing)RobotField extensionObject (grammar)Mathematics
Point cloudFacebookOpen setComputer animation
Transcript: English(auto-generated)
We've got Winfrey today representing the XMPP community, and without further ado, take it away. Right. Good morning. Nice to see everybody here. To introduce myself, I'm Winfrey Thilanes.
Almost 20 years ago, I started off this software as a service, instant messaging service in healthcare, and right now, at the moment, I'm consulting there. And today, I would like to talk about XMPP as a modular protocol, because I think that's
one of the things that sets XMPPs apart from many other things. And it's good to make a distinction between the core basic functionalities of XMPP, and they are made things by the IETF and the IANA, and they are published as RFCs, and they
are extensions, and you can use them for whatever you want to add to those core functionalities. Anybody can write them, and they can be private. You can publish them just as you like. And to have a bit of a look of how they compare to each other, you have the, really the
base RFC on XMPP, two RFCs on ways to transport it, on addressing, including all kind of unicode and addressing, very interesting stuff.
You have then a special use case with use of XMPP for messaging and presence, but you can do all the things with it too. And then I come, name them all in one picture, with all the green blocks, and there are steps, and they can be about ways to transport XMPP, but you can also add functionality,
maybe other functionality than messaging and presence, or functionality on top of that, or they can even depend on each other. So it's quite a bit of complex.
Well, you have the XSF, XMPP standard foundation, it's elected, the elected members and the members elect teams, important team for this talk is the council, they make the protocol decisions.
The XSF corporate, of course, was ITF on the core protocol, but it also publishes its own set of extensions, and those extensions are free to implement for everyone. But others can publish extensions too, for example, the IAE, the engineering, electrical
engineering club, is now about to publish a set of XMPP extensions on IoT, as their IoT standards. So let's have a look at the standards process, a little bit, standards process of the XSF,
a little bit simplified, but you have a nice idea, and you send it to the inbox of the XSF, and then the council decides if it's a nice enough idea to publish, then it's assigned a number, and it's experimental.
Then it can advance to draft, and in experimental it really try, improve it, it's the idea to have many changes still. In draft then it's becoming more or less terrible, but there's still maybe some issues, and then really all issues are solved out, then there are several implementations
of it, it can be promoted to final. And of course, extensions, protocols can also be sidetracked, they can be deferred, and that's automatically processed, then there's no update to an experimental extension
in 12 months, it's automatically deferred. Then there's a new update published, it moves back up to experimental, so that's a two way route, but also CHEP can be rejected, retracted, depreciated, or obsoleted,
and that's end of the line. So that's one issue here, and I have to be honest, from experimental to draft, and from draft to final, that's going very slow, the bar's quite high to move on, so there are quite a lot of extensions that are perfectly functioning and in use with
the stages of experimental, or even didn't have any needs for commit in 12 months, and deferred, so that's a bit confusing, so you really should look at deferred extensions too.
Then there are some kind of special CHEPs, extension protocols, historical, they are obsolete protocols but still in use, so we really published them to document this is still happening around, informational, they are really best practices, how to do certain things or how to use certain parts of the protocol, procedural, that's really
inside the XSF, how the XSF manages things, and the last two of those don't have draft to final but propose an active state, so when you look at the list you may see them too, so you know where that comes from, but let's have a look at that list, and
first of all I always check the deferred also, because there are quite a lot of interesting things there too, and you see CHEP 001, the first one, that's a procedural, CHEP, it's active, I told you about it, and that CHEP exactly describes what I just said, much
more in detail, but that one describes the procedures of the standardization process, and for example you have the data forms, CHEP 004, and that's standard structure, so it's a real technical standard, it's in final, so it's really complete, no issues
found anymore with it, and that's how you can look at this list and see the standards, and well, let's give an example when you click on one of these, how that looks like, I won't tell you what this is about, exactly this CHEP, but very important
to see here, it's a draft, so you can see the status, you see here it's in the standards track, there's some explanation of it, and also you have the abstract, very short, what's about introduction always, or usually mentions the use case, so it's very nice
to have a short look for what it is doing, and also interesting to see, it's also dependent on other CHEPs, so you can see a bit of relations here in the header, but I can imagine you
think I'm getting lost now, because there are 430 CHEPs, oh there's one more admitted I just heard, there's all kind of stuff in there, some of the deferred, as I told you, that CHEPs are widely used, so how do you find a CHEP that you really need for interoperability
that's really widely deployed, and it's something that clients or service may expect you to do, and how to find a CHEP that's future proof, that you're not implementing something that will be superseded quite soon by something new, well we made something
for that too, and of course it's a CHEP, it's an extension, and we make a yearly compliance suit, it's each year a new one, and the old one is obsolete, and it's a list of CHEPs you can use for core functions of XMPP, where you use XMPP as
a means, and for each of these it's split up to a core server, advanced server, core client, advanced client, CHEPs you need to implement, a bit abstract maybe, well this
is how it looks like, this is really the core functionality, and of course all of the core is the RFC 6120, if you don't implement that one you can't call it
XMPP, and then there are all kinds of different functions you may need or may not need in several situations, so when you take a look at this, then you have a very nice overview of what CHEPs you really should look at and consider implementing when you start several
use cases, and also very nice, client servers, library programmers, they all document what CHEPs they support, you see very often even on app stores or on the sites of projects,
this implements CHEP and then you see a long list, so it's very easy to see it, I get an overview from oh, what functionality does it have and doesn't it have, so depending on what you need you can very easily choose, and many of them have a plug-in architecture
and have plug-ins to support additional CHEPs, so it's also very nice to have to look at the plug-ins of such a project, and there's one thing that's very nice when you start thinking about writing or creating something on your own, if you have a nice idea of sending structured health data over XMPP, something like that, you can just write
your own extension, name space for it, and you don't need to change anything on the server, anything you send from client to client is just pushed through, so you only have to make sure that both clients know that extension, and it works, so it's very
nice, very nice, but let's have a look at some CHEPs I really want to mention here, and the first one is a really old one, a component protocol, and I encounter lots of people
who think oh well now I have to connect people in some nifty way, really depending on our use case, and let's write a bot for it, that connects everybody, well that's, I can tell you that becomes totally clumsy, and there's a much easier way to handle use cases like this, and this is a protocol every server speaks, and it's about how
to call an external small objects thing that can do almost anything you like within XMPP, so it's a very easy way to extend your server in their own way, other one I think
that's really interesting and overlooked quite often is PubSub, it's well published and subscribed, and it's a structure that's extremely powerful, any kind of data feed you would like to push to your clients in real time can be done over PubSub, for microblogging
to all kind of technical updates or machines, have a look at it, it's extremely powerful and I think it's rightly in the used. A very exotic one is XMPP, it's a different
kind of transport, over high frequency radio, comes in extremely handy when you are operating a fleet of ships in the middle of the ocean, and it's an example of a very limited used extension for a very specific use case, and another one I really like is InBend Real
Time Text, this was originally made for communication devices for deaf people, and for them to contact emergency services, and the idea of real time text is that old ICQ style
chats, every character you type immediately appears at the other sides, and including the mistakes and the backspaces. And deaf people really like this way of communicating and also I've noted myself that in many emergency line type of situations, people
really like this way of communicating. So these are some examples of things you can find beside the compliance suits in the XAPLists. Well, then I picked this one out of the inbox,
and I see somebody looking up and just put it there last month or some weeks ago. I told you that you can very easily write your own extension and then make sure both clients implement it and then do whatever you want. There are many use cases, people
tend to put messages like that into the message body, but it easily gets very clumsy, so to make it more easy that you even don't have to write your own XAPL for it, you may pick this one, and it just says this is a small container where you can put some
kind of data that's not a message in. And if you want to, for example, program a game over XMPP and get kick started, this may be a nice way to start off.
Then there's one type of XAP I didn't mention yet, that's a XAPT usually published at the first of April each year. For example, this one. It's improving security. It's really
about encrypting big parts of the message, so here's the original unencrypted message and here's a correctly encrypted message. What's happened here? We've seen it. Great
Another XAP from the numerous clients I really like, there's always a big discussion why
I put XML over the wire. Shouldn't we have binary wire protocol? Here you have the nice XML stanza, here's binary wire presentation for it, so we made a nice representation
of sending this over the wire. Helpful, great way to save Pinterest, isn't it? There are in the list marked as humorous. I know of one humorous XAPT that had been implemented, but the guy who did it knew what he was doing. Well, I believe I'm running
out of time already. If you need to know more, all of this is at the XMPP.org website. Whatever you do, don't forget to look at this year's compliance suits. Feel free
to ask hints, tips and assistance. We are here at FOSTA, I'm at the real-time lounge in the K building, but of course you can find us also online in the XMPP DebaDev group chat or in the JDev mailing list. They're really great places. It's an open community.
People are very helpful. Ask any dumb question and you will get a nice answer. Thank you.
We do have time for a couple of questions. Is there any? This must have been set up. So I'm going to do one of these annoying things where you ask a question that you know the answer to. You mentioned that the XMPP Standards Foundation has elected members.
Do you have to be an elected member to get a ZEP published or comment on one or change one or anything? No, not at all. Anyone can submit XEP and even when you write your
own XEP and not submitting it, of course you have not totally free. It's very helpful to be a member of the community or attending summits because when you're writing protocols there are really interesting and good discussions going on there. Lots of information and
all the people involved in it, you can meet there. So there are good places to go, but it's not needed. You can just say, well, this is nice. Let's submit it. Well, is there any questions? I will add to what you said. A few years ago I was working
on an XMPP thing myself, so I showed up with Adrian here to XMPP Summit knowing nobody. And it was a really, really welcoming community, really had a good time, worked together, co-authored one of the ZEPs at some point in time even, not an elected member of anything.
And it was really a pleasant collaboration with you guys. Thank you for your time.