 Bonjour, je suis Romain Gautier, et je travaille pour AF83, et je suis un co-developer du UC Engine, donc je vais vous montrer ce que c'est du UC Engine et ce genre de choses que vous pouvez faire avec ça. UC Engine est un service de subscription publié. Les clients appuient des événements sur le service, qui a disparu à d'autres clients. Ça vous permet de construire des applications de temps, comme collaborer, acheter des services, des jeux, des meetings de vie, ou tout ce qui se passe dans l'événement de philosophie. Mais ce qui fait que le UC Engine est différent de l'autre, c'est sa persistance, sa persistance naturelle. Tous les événements appuyés dans le service sont installés et encodés, donc vous pouvez finir la recherche des événements. Par exemple, vous pouvez spécifier un frame temporaire, ou un type spécifique d'événement de récupération. Ce genre de habileté naturelle permet à vous de penser à des features comme réplique. UC Engine est un service de développement, donc on va essayer de garder ça simple. Nous avons créé une pièce d'application en bas de l'élan, qui est un format de réaction primaire. Et comme c'est une base HTTP, c'est simple, et vous avez des tonnes de fabriquants pour jouer avec. Donc vous n'êtes pas allé à un langage spécifique, parce que UC Engine a été créé pour être technologique, et interoperable, donc vous pouvez utiliser le langage que vous voulez pour jouer avec. Most of your code will run servoside most of the time, because for the moment we have two main libraries, RubyOne and JavaScriptOne, which is focused on the browser interaction. And there is no intermediate between the JavaScript library, your code running client-side on the server, the UC Engine server. But sometimes there is some things you can't do with a browser. For example, there is a conversion of PDF to images that you can't do with a JavaScript API without having a client-side logic. So to add this, you write a daemon client in a browser language to speak with it. And UC Engine daemon client is what we call a brick, a process that needs to be allowed to do a specific things. Okay, starting with a classic, the chat example. Let's imagine you want to chat with a friend, but how do you manage to do this with UC Engine? It should not be more difficult than sending an event to your friend, right? And it's exactly how it works with UC Engine. But let's be clear, you're not so free to speak with your fresh neighbor. So you want to translate automatically your sentences to the appropriate language. So write a daemon client, which subscribes to all chat events. Ask Google for the translations and then push new event to your friend. It's simple, right? UC Engine is built to be generic, as I said. So here you have the behind of the chat protocol. For example, you have messages, events which use of the chat.message.io events type. But when UC Engine sees the messages, the events, they don't know what kind of event it is. It's just events. So it's completely generic. Thus you can build your own protocol. And it's the true power of UC Engine. Because you can build your own interactive protocol. This can lead to a huge ecosystem. You know how UC Engine works? As I said, you know what it's supposed to do. But what kind of thing you can do with it? For the moment, we have a demonstration available on your site, which is usungeon.org. And we show a very subset of what you can do with it. But actually, we want developers to imagine and find their own usages around the real-time application. And by the simplicity and the generosity of UC Engine, the limitations are certainly only your imaginations. I have some links to dig further in the ecosystem. Your code is on GitHub, and we have a lot of documentation to dig further in the ecosystem of UC Engine. UC Engine is a young project. It is fun, and it is free, free as in freedom. And it has been built for developers, you. So contributions are very welcome. Thank you. Now I have plenty of time for questions. Is there any questions? Yes? I don't get it. The question is how the persistence is done. Right? So we have multiple back-ends. But primarily, as we have a Neon Core, we use Nizia, and MongoDB have double back-end. You can choose one of them. Yes? Yes? As we have persistence, we can have replay, et cetera. And we really think we are simpler than Google Wave, because we are not the federating aspect. But we try really to keep things simple and to start really fast. For example, most of your code is JavaScript. So you can start really fast with it, because we have built an ecosystem of widgets which are available on the demonstrations. So you can put your widget on your site, and it works, because you can talk directly to the server. Yes? It's a good question, because I don't really know about this, but maybe we can start with it later, because the core dispatches the event to the clients. But on the client side, I don't know if you can see if there is an event that you haven't, because this is the core which manages this. So maybe it's more complicated than that. Questions? Going once? Going twice? Thank you very much for your presentation.