XMPP: get your shopping cart ready!
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| 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 | 10.5446/47235 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Kummer-TheorieDecision tree learningSoftwareGoodness of fitService (economics)Right angleComputer animation
00:35
Communications protocolKummer-TheorieCore dumpField extensionFunctional (mathematics)BitCore dumpComputer animation
01:20
Stack (abstract data type)Complex (psychology)UnicodeFunctional (mathematics)CASE <Informatik>BitComputer animation
02:21
Standard deviationCommunications protocolCore dumpKummer-TheorieInternet der DingeFreewareKummer-TheorieStandard deviationCommunications protocolSet (mathematics)Internet der DingeCore dumpComputer animation
03:12
Standard deviationProcess (computing)Field extensionLine (geometry)Kummer-TheorieFlow separationMathematicsStandard deviationLevel (video gaming)ImplementationEmailProcess (computing)Communications protocolComputer animation
05:19
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
09:44
SoftwareServer (computing)Client (computing)Computer wormField extensionPlug-in (computing)Data structureAdditionWebsiteClient (computing)Computer architectureMobile appFunctional (mathematics)NamespaceData storage deviceComputer animation
11:12
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
19:34
Point cloudFacebookOpen setComputer animation
Transcript: English(auto-generated)
00:05
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.
00:22
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
00:40
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
01:05
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
01:30
base RFC on XMPP, two RFCs on ways to transport it, on addressing, including all kind of unicode and addressing, very interesting stuff.
01:43
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,
02:08
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.
02:25
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.
02:42
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
03:00
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,
03:22
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.
03:42
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
04:04
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
04:22
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,
04:40
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
05:05
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.
05:20
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
05:47
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
06:06
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
06:26
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
06:44
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
07:05
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
07:25
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
07:41
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
08:04
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
08:22
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
08:52
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
09:06
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
09:22
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
09:41
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,
10:03
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
10:21
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
10:44
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
11:06
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
11:22
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
11:46
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
12:02
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
12:23
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
12:41
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
13:08
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
13:24
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
13:46
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,
14:03
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
14:25
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
14:43
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.
15:01
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
15:23
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
15:54
Another XAP from the numerous clients I really like, there's always a big discussion why
16:01
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
16:21
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
16:45
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
17:01
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.
17:25
People are very helpful. Ask any dumb question and you will get a nice answer. Thank you.
17:40
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.
18:04
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
18:24
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
18:45
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
19:04
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.
19:24
And it was really a pleasant collaboration with you guys. Thank you for your time.