 Okay. Yeah. Mood button is off. Timer is running. But before I jump into my presentation, let me get a feeling for my audience. How many of you have actually heard of SYNC Evolution and perhaps used it before? Well, that's me. Okay. A few people. How many are interested in using something to synchronize for personal information data? That's more people. Great. You're in the right talk, I suppose. And finally, who is a developer and wants to use SYNC technology? Well, there are a few. I hope I don't disappoint you too much, but a better place for that kind of interest will be tomorrow. There is another talk about SYNC Evolution in the cross desktop room. This talk here giving the short amount of time is more like a project presentation. And for those who don't know anything about SYNC and what SYNC Evolution does, let me set the stage by describing the traditional use case that has been where SYNC ML, the protocol has been deployed. That's pretty much in the telecom industry where your network operator provides a server somewhere that a mobile phone can synchronize against. The protocol itself is called SYNC ML, or nowadays the open mobile alliance data synchronization standard. That's the official name nowadays, OMRDS. That's the protocol that the different devices and the server use to communicate. Then in addition to the protocol, which is some kind of XML format with both the text representation and the binary representation, we have the data items that are get synchronized. That's complementary in a way. We have the protocol on top. We have the databases that are getting synchronized with specific data formats that are getting over the wire. Underneath we have protocols to exchange SYNC ML messages. And this scenario that I'm describing here is the traditional one with SYNC ML being deployed over HTTP. And SYNC Evolution as a project fits into the whole picture by being yet another SYNC ML client. That was the original goal when I started with a project, which is something simple which takes data out of my local computer, like evolution and synchronizes contacts, events, tasks and nodes. For that we need a suitable server to talk to. It always takes two to dance in SYNC. One is for client, the other is for server. They both need to agree, first of all, on the protocol. SYNC ML, there are alternatives. There's also active SYNC, of course. But what makes SYNC ML attractive is that it is a pretty open protocol. The standard is freely available. The specification is available. You can implement it free of costs. There are, in fact, quite a few open source implementations of SYNC ML, in contrast to active SYNC. Active SYNC is a Microsoft protocol, pretty closed. And that's why SYNC ML in the open source world certainly is a more attractive solution. So this, as I said, depends on a SYNC ML server running somewhere being operated by someone. For privacy conscious users, that might not be the perfect solution. But it is an easy solution. For many people, it's actually what they want. They don't want to install complicated software on a PC. They just want to synchronize their devices. And that's what this kind of solution provides, assuming that you are willing to give your personal data to someone like Google, Schedule World, or some of the other server operators. Now, the good news is there are other ways to do SYNC ML, for example, between a phone and a PC directly over Bluetooth. And as you will see, we are actually working on that. So if this is not your cup of tea, keep listening. We are going to get there eventually. So a little bit of history. SYNC Evolution used to be my spare time project for quite a while. Until the beginning of 2009, my employee, Intel, took an interest in the project for the Moblin distributions. So the slides probably are familiar. That's the Moblin-themed ones that we are using. And since the beginning of 2009, I've been working on SYNC Evolution full-time, also with the help of other Intel colleagues. It used to support local data stored in the Evolution data server, your Evolution mail program, basically. And that made it very suitable to also deploy it in Moblin, which also uses EDS. So that's the traditional usage. Then at some point, I ported it to the iPhone, as it came out, to jailbroken iPhones, of course, and Mac OS. At that point, the name was less suitable, perhaps, so I chose a new tagline, the missing link, in order to not having to avoid a re-named project. And that's pretty much the situation that we have today. It is a SYNC program that works as a product for users very well with Evolution. It's currently unmaintained on Mac OS, but if someone would be interested to take over that, the source, I think, still more or less compiles. It supports other platforms. It's certainly meant to be more than just a PIM tool for Evolution. Other platforms that have been added over time was a port to my AMO, the original one. It was done by me. It still depended on EDS. That was in the platform, at least for contacts and also for calendars with some add-ons. Now, more recently, Overcarven has done a very good job of porting it and making it available again on my AMO 5, the current distribution that you have in the Onokia N900 device. And in addition to that, he also wrote a calendar backend because now in my AMO 5 there is an official PIM storage for calendar, which wasn't in earlier distributions. And given with that backend, you can now synchronize also on my AMO. And I think he is also working on a GUI. That is something that will be on the next slide. It used to be a command-line tool, SYNC Evolution, and GUI is something separate that I was personally not so much interested in, but it's certainly useful for users. Now, we have a big desktop platform that I hope will support eventually with help by other developers is KDE. And I just have been at the KDE PIM developer meeting discussing that with KDE developers, and they are interested in. There is a tentative Akonadi backend, but it's not production ready yet, but it will be at some point. And what I already mentioned, direct synchronization. Taking your mobile phone, currently you have to enable Bluetooth, USB won't be supported immediately, and synchronize directly with your PC, where you have SYNC Evolution running on your desktop as a normal application. And that's what we will have in 1.0 to some extent. More on that on the next slide. Now, the big question, of course, is there have been so many SYNC projects. Why should this one be successful, and why should you trust it with your personal data? Well, one thing is we are building on something that has been around for a long time. Now with the current code base. And I can't stress that often enough. The company SYNC has done a great service to the open source community in the beginning of 2009, when they open sourced their SYNC ML implementation. I was in contact with them at the time, we were discussing it, and then we both went public with the news together that SYNC Evolution inside Moblin would be using the SYNC engine, which became open source then. SYNC's company is fairly small. They have been around pretty much since the beginning of the SYNC ML standard initiative. And the key difference between their implementation and the other one that I was using before from Funenbol is that the SYNC code base is a complete SYNC ML implementation for both the client side and the server side. And exposing the same APIs more or less for the data backend. And so you can write a plugin back end for SYNC versus SYNC Evolution and it will work pretty much the same way on the client and the server side. And first of all, for the solution in general at all, it is possible to write a SYNC ML server given that code base. It's not just the SYNC ML protocol that it implements, but also very important all the data handling and conversion code is also in that code base. That's something that unfortunately is necessary with SYNC ML because there are so many different ways to implement vCard and vCalendar that you really need good code that is good at parsing things that are might slightly broken. You need a lot of tuning knobs to generate just the right vCard that your specific device is able to swallow. Like if it has a length limitation on a specific fields, that is something that you need to be able to parameterize in the engine and the SYNC versus engine has that because they have been basically doing this kind of thing for 10 years. And now it is available in the LGPL 2.1 and 3.0. So it's also something for the developers among us that is easily incorporated into some other kind of solution, even if it's proprietary. Of course, there's also a commercial license from SYNC versus if you need support. So that's the business model. Now for us, with SYNC Evolution, we are currently in the last phase or we're still in the 1.0 release phase. We're hoping for release end of March, beginning of April. Big new feature will be the direct synchronization. But before you get up your hopes too high about really just getting an arbitrary phone to work with your Linux PC, I have to point out that what we will have in 1.0 is just the mechanisms, the infrastructure to actually make a device work with Linux PC. What we don't have and what we need to build up over time is a database of how to talk to specific devices. And unfortunately, that's something that depends a lot on the specific device. To just get it to start talking in Gmail via Bluetooth, you need to send it the right message with the right parameters about database names. You need to identify yourself with the right string. Otherwise, it will just cut the connection and don't really refuse to do SYNC over Bluetooth. So we need to gather more information about specific models and the quirks and all of that. And that is something where we hope to get support from the open source community because clearly it is a huge task and no one is going to have all of the devices that anyone wants to have if all the users want to be supported. So for devices, we really depend on contributions to build up that database. We call it config templates. What we currently have for services is something that we actually do test ourselves. We do nightly build testing and compatibility testing with a variety of SYNC ML servers. But that's just a handful or perhaps I need two hands by now. That's manageable, but there are thousands of devices, so clearly we need help there. The other area where we could branch out beyond 1.0 is adding more support for local backends. KDE clearly is the big one missing at the moment, but that's getting worked on. I also have the idea or the plan that this could be useful for also non-local data like something that is accessible via some kind of protocol like PBAP via a phone that doesn't support SYNC ML. We might give you contact access via PBAP. If you write a back-end using another protocol to expose the data, that's perfectly fine. We do have one example in the current distribution, a SOAP-based back-end that was contributed by an Austrian company. They are using it to access the data that is stored in their web service and they are synchronizing that data via SYNC ML with the help of SYNC Evolution and the custom block-in that they wrote. The same thing with local sync between two databases. That requires having two back-ends active at the same time, one as a client, one as a server and then getting them to talk among themselves. That's currently not supported simply to simplify the implementation. It's not a conceptual problem. We could certainly add that feature and I hope to work on that immediately once one is always out and I got a little bit more spare time to actually spend on something like this. Now usage, well, as we all know in the beginning there was the command line. Then Frederick Albert, he's actually around here somewhere in the back but because I'm running out of time I'm not, oh, he moved here. Well, stand up perhaps for a second. He's the one who contributed and developed Genesis in his spare time and it's sitting in the applet. It was the first graphical interface for SYNC Evolution. In Moblin we added the SYNC UI which is a GTK-based full application in contrast to Genesis which is more tailored towards sitting in the panel in the applet. Because we just did a major redesign of the 1.0 for the 1.0 of the GTK UI let me show off some of the new designs. That's the conflict dialogue with a lot of, well, just unfolding a certain template for Skity World for example will let you fill in the necessary detail and then you can start using it. We also added some more error handling facilities both in the core engine and in the GUI. So the graphical user interface is now able to do a lot more with specific error codes. In this case it identified a problem with logging into the SyncML server and it helpfully suggests that you might want to edit your service settings like correcting your password or username. Now another thing that can go wrong unfortunately with SYNC is something, well, sometimes things just break, shit happens. So what we have is an automatic backup facility in SYNC Evolution basically taking a database dump before and after a SYNC and now in 1.0 we also have the possibility to restore from that via the GUI. Previously that was a command line only feature but it has been around for a while pretty much since I started with SYNC Evolution because I knew that I just can't trust SYNCML servers all the time. Sometimes we might want to have a fallback solution. Now the other solution then is to do a refresh either from the server to the local client or from the local client to the server depending on where the right data is and that's now getting exposed via the GUI. Again, that is something all that has been in the command line tool for a while. Now coming to the end of the talk, well, pointers towards more information are clearly on the project website that's SYNCevolution.org and as I said at the beginning there will be another talk with more time for questions, more technical content about SYNCML tomorrow and with that I invite you to join that talk tomorrow.