 So, yeah, I'm Flavio Percogon, the current PDL for the open-stack messaging program, also co-name is Zakar, or Zakar, I don't even have to pronounce it honestly. And, well, as it has already been said, we're just going to go through the killer plans that we've kind of discussed back in Paris at the summit. So, if we get to the next slide, before we even get started with the killer plans, I'd like to take a little bit, a few minutes of time, and find out what Zakar actually is. And before you even ask what Zakar means or what the name comes from, the name is actually the name of how misopotamians, like in the misopotamian mythology, there were some messengers for the god of sin, and those messengers provided those messages through nightmares and dreams and to people. And, obviously, the relation with the name is about the nightmares and not exactly about the messaging part. So, that's where the name comes from. It is Zakar, we had to change the name. The project was previously called Marconi, and there were some issues related to the name, and we were basically forced to change it, and this is what we came up with. So, now that I've said this, let's get to something more technical in the next slide. So, 101 about Zakar. Zakar is like a really protocol, like Zakar is the messaging service for OpenStyle. It's not the only one. There are other solutions for different areas. The key thing about Zakar is that it is a data API. It has a data API. That's what it provides. It doesn't provide any provisioning API. It provides messaging features and solutions for different messaging patterns, and obviously it wants to be easily scalable and easy to maintain and provide all the Python libraries that are needed to interact with the service. If you are familiar with other vendors, Zakar would be something similar to either Q, service, or even AWS, SQS, and SNS put together. So, when it's put together, it's because when you're reading messaging in Zakar's description, which by the way, what I put in that slide is actually a mission statement that we have in the governance report. When you're reading messaging there, we are actually referring to not just the ability to send and receive messages, but also the ability to have notifications on different kinds of notifications. And that's actually something that we will be working on during Kilo, and I think it's the next point in the next slide. So, yeah, we can move to the next slide now. So, notifications. There are a few things that – no, first one. There are a few things that we actually want to work on in Kilo, and we tried a lot to keep the list small, because in previous summits we came up with many ideas, many things we wanted to work on, and obviously time is limited, and we kind of went through all the feedback we have gotten so far from the committee and different discussions on the mental list, and we decided to take really like very few things and work on those. And there are two main features that we want to work on. So, there are brand new features that we want to have in the service during Kilo. One of those is notifications. Like I said, Zakhar aims to provide notifications as well. So, we're going to go ahead and implement these as part of the new version of the API. We will add notifications so you will be able to subscribe to the service in many different ways, and we're not talking about notifications in a way that you would probably get them from private inquiries so that you would just connect to the server and get notifications. Messages basically pushed back to the client library, but we also like to have different kinds of notifications like pushing messages through a mobile, APNs, emails, even SMSs or text messages. But that's part of the future, and the things that the two publishers that we want to focus on for the Kilo release are actually web hooks. So, you would subscribe some URL to the service and when a message, and you will actually subscribe to a queue, so a specific queue or topic if you will. And so when messages get there, you will get them in that URL that you have subscribed. Or you can also get those messages back to the client if you have a connection to the server or persistent connection, which actually takes us to the next thing we want to implement, and I think it is in the next slide. So, yeah, persistent transport. This is something that we currently don't have. So, Zucker is pretty much – I hate this word, but I'm not going to use it anyway because it's actually pluggable. So, you can create different plugins for different parts of the service. And we have this pluggability in the storage side and the transport side of the service. For the transport side, though, we don't have any plugins besides the one we support right now, which is HTTP. And that basically means that if you want to talk to the service, you have to use an HTTP client and you have to send the HTTP messages request to the server and it will process it for you. And something we want to have definitely is the ability to connect to the server and keep that connection alive so that you don't have to see – you can basically work around the burden related to HTTP and the overhead of the protocol, which it might be load, but it still exists. So, we want to have the ability to connect to the server and have that persistent connection there. And something that we also want to have is better support for browsers. And therefore, we have chosen WebSocket as the protocol we will use for the first implementation of a persistent transport. And WebSocket is – I mean, it has been around for quite a few years already. I'm not even going to say like a long time, but it has been around for quite a few years. There are being different many iterations over the specification of the protocol and where it is being supported by most of the mainstream browsers nowadays. So, we wanted to have something that is CRES browsers and it can be used by many people from the browser. And the – I mean, in addition to that, WebSocket can also be used outside the browser if you have a WebSocket library for your preferred language. You could use that library and talk to Zuckar using a WebSocket transport. And that's something we will actually do in Zuckar Client. We will have support for WebSocket from there as well. And it will – hopefully, I mean, type of meeting, it will do something fancy like falling back to different protocols based on what's available in the server. So, in implementing this persistent transport will also require us to have a kind of different implementation of our current protocol or current API. So, the API in terms of actions won't change at all, but it will change in terms of form because it will be kind of – for the persistent transport, for the WebSocket transport, it will kind of convert it into something that is serializable and that can be sent through a WebSocket. So, we will kind of translate what we have in HTTP transporting to some kind of dictionary or something like that that we will be able to send to the server through WebSocket. So, that's probably the gif of this work here. And I'm very keen on what we're doing here. So, looking forward to have it ready. And so, we can now move to the next slide. Can we move to the next slide? The other thing we want to work on is storage capabilities. Storage capabilities is not – so, we have all these – plugability, and like I said, we have these plugability in the storage side as well. And we are able to – I mean, you can write your own storage driver and use it from Docker. But this storage driver currently has to support every single feature supported by the current build team storage drivers that we have. And we want to make this layer more flexible so that other people can implement their own storage driver that don't have to necessarily live in our code base. And those drivers can – these people need, depending on what they want to do. So, in order to do that, we need to convert all the features that we have currently in our storage driver into something called capabilities that we will expose through these storage capabilities. And we will expose those in the API through flavors. And these capabilities basically are a way for the driver to say the things supported in it. And, for example, a driver may opt out from supporting claims or it may opt out from supporting FIFO, depending on what technology it is sitting on. And it may also opt out from supporting durability and in favor of a higher throughput, for example. And this is actually the base feature that we need to have in order to implement the next one that we have online. And if you want, you can move to the next slide now. And, yeah, so the next one that we have online is actually optional FIFO. And, I mean, the previous one was basically the basis for implementing this. Because – so something that we have discussed – at the very beginning when we started working on Dakar, like I said, at the time it was called Marconi, when we started working on it, we got some feedback from the community. And something that the community said to us is that FIFO – not having FIFO in services like SQS was actually very painful. So we heard their feedback and we wanted to have full support and like 100% guarantee of FIFO in the service. And we did that and we have – the current released version has full support for FIFO. But it turns out that the FIFO has – there are two issues basically related to FIFO. The first one – I mean, it's not bad itself, but there are some things related. The first one is that there's some overhead related to FIFO, depending on the storage driver. You would have to do some magic to actually guarantee 100% ordering. And some technologies may have it built in, others don't, so you may have to do some work around and hack it somehow in the driver. And along that line, there are some technologies that won't support it at all, which is the second issue that we have. And since there are very valuable and good technologies that may be a good fit for a Dakar storage driver, we don't want them to have to pay the price of something that we have chosen as a need for the service. So after hearing the latest feedback that we got from our community, from the OpenSight community, we decided to make FIFO optional. And it will depend on the driver itself and how it is configured. You can basically opt in or opt out from having FIFO in a third deployment basis, basically. So this is something that's definitely coming in Kilo as well. We can now move to the next slide. We're basically going almost at the end of my presentation. I don't think I'll use the whole 15 minutes or probably already use them. Can we move to the next slide? Okay, perfect. So keys to topics. This is something that we haven't decided yet. So time permitting, we would like to... If we have enough time, we would like to rename what we have right now called keys. We would like to move from having keys to something called topics and stop having a first citizen resource that we need to create in the database. This is just a peer optimization for DACA internally so that we can save space in the storage. So storage technologies that need to have the key resource created, they can still create it. But if there's no need to do that, like the MongoDB one that we have and the Redis one, you can just skip and don't create at all. And we would like to do this, like switch from keys to topics which would be like a more lightweight resource to have in the service. But this hasn't been decided yet, so it may or may not happen before the next release. We can now move to the next one. So I think that's pretty much it. If we go back to April 2015, we will have a release that has notifications, persistent transport storage capabilities, and optional FIFO. And well, the dots down there is because prioritizing things is actually harder than time traveling. So things might be moved to the next release or some other things may come into this one here. So at the high level, this is what we would like to do. No promises made. We will hopefully have all these and more, but we will see. And we will move to the next slide. This is the 30th yet. I mean, to be continued and yet to be told, we will see what happens in the next release. But if you have any other questions or you would like to join in help and with anything and you are interested in the project, please, we are all at openstack-zacar-free-node. And I'm Flavio Parcocas already set. My email is flavioatredhat.com and I'm Flapa at 87 on IRC and Twitter if you have any more questions. Thank you very much.