 Cześć, cześć. Czy to działa? Więc moja nazwa jest właściwie Bartłomia, Bartłomia Górna. O nie, to nie jest dobra. Przepraszam. Ja pracuję na Erlang Solutions. Jestem jednym z kodowelopów z Magdoriem, który jest ekstasyjnym piosenkiem XMPP, na przykład na msg w Erlang. Przestałyśmy zacząć, żeby zrobić ważny dysklamer. Może być kilka ludzi z XMPP, sztandardów, fundacji w romie. To są ludzie, którzy nie mają XMPP. Muszę powiedzieć kilka rzeczy do nich. Proszę, proszę, przepraszam. Zobaczmy, co ma w porządku z protokolą. Potrzebuję odnaleźć jakieś krótkie rzeczy, żeby zrobić dysklamer, czy niebezpieczny, czy niebezpieczny. Możecie się zauważyć, jeśli naprawdę musisz mnie zabić, proszę zrobić po dysklamerze. Tak więc, będziemy rozmawiać o innowacji. Co innowacji jest? To są dwa rodzaje nowych rzeczy. To jest innowacja, to jest innowacja. Formalna definicja z nich jest, że innowacja jest coś, czego naprawdę nie jest, jakąś nową ideę, projekty, coś nowego designu. Innowacja to właściwie implementacja z innowacją. Więc możecie przeczytać to, że to jest formalna definicja filozofika. W końcu, idea, innowacje, innowacje zmieniają się, innowacje, poszukiwają idea w motyku. To naprawdę mało. Więc w naszym razie, innowacje będzie coś nowego, czego chcecie zrobić, używanie instancji, pewnego serwisu, pewnego miejsca, i innowacje będzie implementacja tych. Więc albo, alternatywnie, innowacja może być nowa, nowa sposób, żeby zrobić coś, co już się pojawia. Są już idea, co jest zrobione w innowacyjnym sposób. Więc w naszym razie, to będzie innowacja, to jest innowacja, to jest to, co będziemy mówić o tym. Jak możemy innowować używanie tego protokola? Jest to traf o rozgrzewaniu rzeczy. Ponieważ protokol jest rozgrzewany, to jest część jego nazwa. Więc to jest łatwe, ale było łatwe, to jest wystarczające. Na przykład Drupal, z CMS, w PHP. Pięknie, dobrze zauważył. To jest bardzo rozgrzewane. I wreszcie, jest to, że homo-page od Drupal jest troszeczkę poniżej 22 tysięcy rozgrzewania. Więc dobra reakcja, dobra? Wydaje mi się, że jest to rozgrzewanie. Jest to fundacja standarda, która zauważyła to. Jeśli chcesz zrobić coś nowego w protokolu, to jest to procedura standarda, która nie jest łatwa. To jest długo. I wreszcie, nie jest to 22 tysiące, ale 150 tysięcy, oficjalnie rozgrzewane. I to jest zwykle nie rozgrzewane. Jeśli chcesz zrobić coś, to chyba znajdziesz tylko jeden rozgrzewanie, co to robi. Jeśli to jest jedno z nich, to jest zwykle nie rozgrzewane. Więc chodźmy. Jesteś familiarizmą z PPM? Tak, przez kilka ludzi. Więc to będzie rozgrzewanie dla początków i krótkich rozgrzewania na południach populacji zoomu. To jest protokol kliński, kliński kliński. Bo zwykle kliński komunikuje via serwera, ale jest stworzona federacja. Więc kliński może użyć różnych serwerów w różnych domaniach i te msg. są przejście. W niektórych okolicznościach kliński komunikuje od razu, ale nie idziemy pokazać tego. Teraz XMPP pracuje przez rozgrzewanie stansa, stansa jest strukturą XML, i są trzy typy stansów. Nie może być więcej, niż trzy typy stansów. Nie może się innowować przez tworzenie nowego typu stansów. Jest IQ, która ma trochę zrozumienia z inteligencją, rozgrzewa informacje. To jest normalnie używane dla komunikacji klienta i serwera. Jeśli chcesz zadać kontyguracyjne parametry z kontekstów, czy chcesz zadać msg. Użyj IQ. To jest prezent, który normalnie użyje serwera, based on data provided by client. Więc sometimes client can send presence like I'm busy. And this is distributed to the friends of this client. And sometimes if this client loses connections, then server automatically says this guy is unavailable and distribute presence to other clients. And messages are, again, normally just shipped from client to client. Server does not do much with the internals of the message. It's just like, it's opaque for the server. This said, right. And how does the stanza look like? This is a typical message. This Bernardo can send to Francisco in Verona or somewhere else in Italy. This is the name of the message. This is its type. It's addressed from two. Often messages have ID, which should be unique. And this is the inside the stanza. This is just the body of a message. This is the most simple stanza you can possibly do. There are a few predefined types, which are also non-modifiable. For IQ is get, set, result or error. So if you set some parameters, you send set stanza, you get result okay. Or error. If you get, you get result like your messages from an archive. For presence, it can be empty. Empty presence is unavailable. Or unavailable. And so on and so on. I mean, I could talk about XMP till Thursday. So we are just going to scheme along the surface. Messages are normal messages, which is just one-to-one message to someone. Chat. Chat is a part of a longer conversation. Group chat is group chat. Now what's inside the stanza? Inside the stanza are things that are, there's a payload, which is processed by server or by client or by boat. Hopefully by somebody. So this is, for example, a simple presence, which has, it may be empty. Empty presence is just unavailable. There can be more. For example, this stands for do not disturb. This is some short comment. I'm on a call. So if your instant messaging client receives something like this, it's probably some little stop sign. I do not disturb. And this slide underneath. And this is call protocol. This is defining very basic documents. This is global namespace. Nothing fancy in this. And now and pay attention because this is the most important slide of the whole presentation. An element can introduce its own namespace. For example, this is what we had before, right? We just show you, I'm on a call. Do not disturb. And then we have something like mood, anoid and text. Which basically mood has no meaning in the global namespace. Text is ambiguous. What a text is. But this element introduce its own namespace. And within this namespace stuff like mood anoid and text are defined. So your job of clients will show you somehow one way or another that the guy is anoid and whatever. Or if your client does not support this namespace you just ignore it. And this is actually an extension to the protocol. This is called XEP, XMPP extension proposal. And we can use alternatively feature, extension, ZEP and namespace. Because this is exactly the same thing. Every feature is defined in XEP and every feature has its own namespace. So all right. Because every feature has a namespace then if we ask a server for example what can you do for us? What features do you support? It's replied by sending us a list of namespaces. Which is basically which maps one to one to the list of ZEPs that this server implements. So this in XMPP parlance this is how we call it. This is by the way another XEP which service discovery. All right. So this is the namespace of service discovery. This go info and this is the server's reply. I need to rush because there's quite a few slides ahead. Namespaces can be nested. Because they can be within namespace the deepest nesting I found so far was three levels. It was jingle negotiating file transfer. This is actually a honking great idea because it makes things very easy to implement. If you have an XML structure you just iterate deeper into this if you find namespace you can hook a callback for it to handle this namespace if there's no callback then just skip it and this is done. So this can make code very orderly and you can play with message payload however you want. For example this is just a message saying I'll send you something in a while. So we receive this message and the other guy keeps typing and our client shows us that he is typing or some icon or whatever. Every I am client does this. This is because we receive this message which has no body. It doesn't have to. But it has it uses another extension traffic notifications. I told you there are 150 extensions so there's quite a few things to talk about. This is chat states and chat states define composing state which means what it means the guy is typing. So there's a lot of freedom in it. All right. XNPP is very well documented. This is because those XSF guys are really tough and they demand very good concepts. So there RFC defines basic features and there are those enhancement proposals. They all look pretty much the same because the format and the style of writing has to be the same all the time. So there are hundreds of them because it's not on extensions. Except defined formats of address, lots of stuff, best practices. They are pretty verbose which takes a while getting used to but it's a matter of personal preference whether somebody likes it or not. They are all listed on the website and the most important step of all except 0001 which tells us how to write zeps. So it's sort of a meta step if you will. Now to the point what if you want to extend the protocol? How do we go about it? First thing is read existing zeps. Really. Because it's very rare that somebody comes up with an idea that it has not been already covered. What happens? The good thing about them is they are really bullet proof. I mean there are a dozen of people who read them and discuss them for a year or longer before they get finally accepted. You are likely to find an extension that you can extend. Because as I said you can nest namespaces. So you can put extension within extension. And to give you an example let's say you have an idea that chat state can tell more about someone. Because chat state tells us that somebody is typing. But it doesn't tell us how he is typing. Is he nervous typing very fast? Or he is just slowly letter by letter watching TV or corner of his head. This is very easy to do in client, right? To measure typing speed. But we already have chat state, right? We don't have to do it from scratch. We have chat state. So this is actually nothing that could stop us from doing this. This guy is furious. He is typing like 500 characters per minute. So this is our extension. No official number. Read chat state notification. Namespace. And this is what we do. And we have furiously, lazily, sloppily, whatever. Nervous. The syntax is different, but namespace is just arbitrary string. So this is old syntax. This is the new. The currently preferred one. Chodź na stanca. For client's service IQ. For client's client's message. Do not use presence. Why? Presence is generating too much. It's a very tempting to use presence. I will show it in a while. Presence generate very much traffic. 80% of instant messaging traffic is presence. It's not messages. They go to everybody whether you want it or not. And there are much better ways to do that. For example, let's say you have an idea that we want to provide geolocation of a client. The client can be a physical person or a device mounted somewhere on a truck or wherever. So the first idea is, well, it's presence, right? This guy is present at a certain location. So what can be more obvious than using presence for this? So when I first thought about this, this was my first idea. And I thought, well, I'm so smart. It's so obvious. I know dispute of XMPP. It's presence. So doing something like this. Presence, we insert location element. Done, right? No. And there are at least three reasons not to do it this way. First, as I mentioned, location goes to everybody. So every one of your friends will be flooded by your presence carrying location, whether he wants it or not. And there's no way to get rid of it. Because he wants to get your presence, but not necessarily location. He doesn't want, like, five presence per minute showing him that you are riding a motorcycle or whatever. And it's not archive, which is something that we might want in this case. Reason number two. Is that there is a very neat thing. It's called personal eventing protocol. Because there is pubsub. Just publish, publish, subscribe. There can be a node. You subscribe to the node. You get information. If the server implements ZEP 0163, it means that it supports personal eventing protocol, which basically means that every user is a pubsub node. So you can subscribe to events generated by this person. So now the location would go only to people who really want it. Because they subscribed to it. And the guy has a control over who gets his location and who doesn't. And reason number three. Arguably the most important is that it's already done. So that's why it's recommended to read or accept before thinking about anything else. Then free your mind. Because you can put anything you like in the stunts. Provided you obey certain rules. Then you have, of course, design sequences. If the server receives this stunts, then it must reply with something or error, so on, so on, so on. It's highly recommended to write ZEPs. Because it makes you think again about what you've done or what you're about to do. It's good to have it because it's consistent. So if your developer read 70 ZEPs from the core protocol, that would be easier for him to read another one written in the same fashion. And try to have it approved. It will get rejected, but you will get some feedback. Now, we've actually done this a few times. Yeah, I know, I have one minutes, right? Okay, I have two slides, one minute. Secret message. Somebody wants to send messages that are handed differently. This is actually a real life case. So, again, the first idea is message type, right? This chat, this secret chat. No, no, don't do this. You will break everything. This is the way to do this. Insert another namespace, flag the messages secret. The server is a piece of cake to implement it on the server. Client can also handle it easily. And the other one is MOOC Lite, which I would very much like to share with everybody a lot, but you can do it afterwards. It's a simplified lite with a version of multi-user chat. Because multi-user chat is more scalable. We submitted it to XSF two years ago, and we are still trying to have it approved. Chances are slim. But we are not giving up. And we use it in production on any sites. So, it's somehow more or less proven to work. Thank you very much. I really have to finish. My try to serial, so we don't lose it if we get late with some sessions. And also as a speaker try...