 Hi, I'm Christian Molikov and I'm going to talk to you about CUBE. For those who don't know me, I started contributing to KDE about nine years ago and for the last four years I've been responsible for the desktop client for Collab Systems who develops the Collab Groupware Server. So what is CUBE? CUBE is a modern communication and collaboration client. It's email, it's clandering, it's task management, but it's also instant messaging, note-taking. That doesn't mean that we do all that right now already, but that's sort of the scope that we want to work within. So it's built using Qt Quick on top of a high-performance core called Sync and it's developed within the KDE community. We have other members of the KDE community that are part of the development team, especially the visual design group, the KDE VDG, that helps with a lot of the usability issues. So for some of its goals, we aim to be pretty and useful. So we don't want to make a toy that just looks pretty, but we also believe that in order for people to like to use the application, having a clean user interface helps a lot. We want to have a maintainable co-base, so that means we have a focus on testing it well and having it automatically tested so we can move fast without breaking stuff. We also have a focus on deployability. What I mean by that is not only portability, so we want to target MechOS X, we want to target Windows, but we also want to go on mobile platforms eventually, so we try to keep our dependency chain in control and only depend on things that we really require. But by deployable, we also mean that we want to support automated setups, so if you have large deployments, which we, for instance, do with collapse systems, then you want to be able to script most of the setup process and have the necessary tools for that as well. Cube should be a high performance tool when you require it, so it gets the job done quickly. We think that is important, that you don't have to wait for the tool, but it also shouldn't get in your way if you're not actively using it. So if you don't use it, it should get out of your way, and if you're using it, it should be there. Another target that we have is to make secure communication easier and more effortless, more about that later. But where are we right now? Cube is in a fairly early state of development. We've worked on it for the last year, but it was a lot of framework building, figuring out the architecture, preparing, so that we can scale up the development as well. So initially, we're focusing on email only, so we're building a simple email client as our MVP of sorts, because that's just the hardest use case, data-wise. So if we can deal with a million emails or, say, folders that contain like 60,000 mails or so, a-to-do list is not going to be a problem. That's why we're focusing on email first. So that's pretty much the current state of Cube. It's very fairly basic so far. We can get to the mail, we can show the mail, we can render plain text mail, we can render HTML mail. We have the encryption or the whole GPG stack, I'm already included thanks to code that we share with the rest of KDPim, so with contact. We have support from multiple accounts, but that's pretty much where it is right now, so it's still quite a bit away from being useful for end users. If we have time, I'm also going to do a quick live demo at the end, but we'll see. So in order for you to understand whether this application could also be useful to you or whether you would be interested in something like that, and ideally, of course, whether you'd be interested in actively working on it, I'm going to highlight some of the focus areas that we have to hopefully show you where we eventually want to go. For users, I think one important aspect is that we want to focus more on workflows. So traditionally we have like email application, we have a calendar application, we have a note-taking application, but they're all sort of separate. They perhaps integrate a little bit, but not a lot. However, the tasks that users actually have to do often involve a variety of these different applications. So if you think of a workflow like organizing a meeting, you have some communication initially, perhaps, then you have some scheduling, which could be done over the calendar. Then at some point you have the meeting, for the meeting you probably have an agenda, which is sort of a task list that you maybe want to run through. During the meeting you're taking notes, so out of that come meeting minutes that you perhaps have to approve again, depending on the nature of the meeting. So there is quite a variety of different tasks in there where we think we can support the user better if we model that and not just give him an email application and the calendar application and then leave him up to figuring it out himself. Another focus is certainly usability. We work closely together with usability experts and designers from the ground up. We try to build that into the development process that we do that regularly and not as an afterthought. We don't want to solve all possible use cases with CUBE. We believe that for a good user experience we have to figure out which problems we have to solve and then focus on them and try to solve them cleanly and just do what we do right instead of just adding features because we could. Another focus point in regards to usability is certain the whole security aspect because currently this is just fairly complex leading to users not using encryption for instance because you have to set it all up yourself and we believe there are a lot of opportunities to improve upon that by integrating for instance the key management into the address book by using things like trust and first use by having a simple visualization integrated with like the color scheme green yellow red. So you recognize immediately whether a communication channel is secure or you don't know or actually insecure because the key was revoked for instance. CUBE is first and foremost a network application because if we're building a communication and collaboration solution we're going to want to communicate with someone and what that means is we focus only on content that you have typically stored on a remote server. We don't want to rely too much on local data because if we do that then we for instance break the multi device use case so if you have a web interface you have a laptop you have perhaps a mobile device if you rely on the local data of one of these devices then you're not going to have that same data available on another device so therefore we believe we should take this as a as a focus point and say okay that if the data is not available on the server then we're not going to use it that doesn't mean you can't use it with local data like a mail here we for instance have right now a mail here back end for CUBE which then just treats the mail here as the remote content but that's just not really the focus point. Of course we are doing all the network access over open protocols as far as possible that's currently just IMAP for for accessing the email and the DAF protocols for address book and calendaring. From the development perspective I think one of the most important aspects is that we are trying to build reusable components so that's sort of in preparation for what I was talking about earlier that we want to start mixing up different application types if you will. So for instance if you have an address book you render the contact in some way so that could be a component that is then can then be reused for instance in the email view if you click on on the sender or or some other sort of contact. So that way we enable consistency but we also enable use cases by allowing to for those components to be used outside of CUBE. So these components can be installed as K packages which is just a folder structure essentially bundling a QML file with the plugins necessary to access the data so the component itself knows how to get to the data. So if you have a calendar component you could for instance show that in your desktop clock applet and then you get the full power of your regular calendar that you're used to inside that clock applet. One of the major problems that I want address with CUBE that I think quickly becomes a problem in a project of that size because if we're going to work on that for a couple of years it's going to be a fairly large project. The problem there is complexity. Complexity can very quickly become so big that you can't really move anymore and that it feels a bit like a Ruben Goldberg machine where you touch one part and then something else moves and that triggers another process and that just becomes very difficult to reason about after some time. So in the CUBE architecture on a very high level it looks like this. So you have these are processes. You have the CUBE process and you have here two backends that are called resources. So that could be for instance an IMAP back end and that could be a called F back end or it could be two different IMAP servers and then you have a library so that would be the API that CUBE is built against and that provides a unified access layer. So from the application perspective it just queries for instance for emails or it queries for calendars or it queries for events. It doesn't really know that there are multiple resources respectively doesn't really care. If we zoom in on that then the green box is the resource. You have declined generating commands so if you modify an email or mark it as read or delete it it sends the commands to the resource. The resource stores it in a queue. Then all the resource does is essentially processing that queue. It just processes one modification after the other and all these modifications go through a pipeline. The pipeline contains different steps that's an extension point for us to process modifications before they hit the store. So in there we could for instance do things like filtering or so to folders. So and once that pipeline is processed we hit the store. A notification is emitted that the revision of the store has changed that's just never increasing revision and then clients will just update once they get it so they just replay the changes. On the other side we have the source which would for an IMAP resource that would be the IMAP server. So we have a process synchronizer process here so not a system level process but just something that figures out what's the difference between the server and what I have locally. Generates a bunch of changes throws them in the queue. The resource processes it exactly the same way. If the change didn't come already from the source then the right back will just it also listens to the revision and will just replay any changes that didn't come from here to the source again thus synchronizing the state. So what we get are these nice reactive loops. So the client all it does is listen for changes and it has a bunch of models that are essentially self-updating and that just replay those changes and on the other side you just fire commands at the resource and then you're done. So that becomes it becomes much easier to reason about the system and it allows us to mostly contain the state to the database. So we don't have different parts of the system that maintain their own state and that I believe helps a lot with keeping complexity at bay. Another important aspect is certainly performance. Our approach to performance is not necessarily to try to optimize things as far as possible because that is always costly and might introduce more complexity. So what we try to do is to not do unnecessary work and do the work only once that we have to do. What that means first and foremost is queryable data. So we have to be able to query for exactly the data that we actually need for the task attend. So for instance if we have a large email folder say 60,000 messages or so. If we can't query for the data we're going to have to load all those messages sort them for instance in memory and then throw 90% of them away again or 99% because you actually only have space for like 15 or so. What we're doing instead is we're building the necessary indexes to be able to query for exactly that data. So we can query for instance for the first 100 emails in a folder sorted by date and then we load exactly that and as you scroll down in the view we just fetch more. By not only doing it once I mean we don't do we try to not do the work when we read. So if you click on the folder and it loads the data we don't want to re-sort your whole list every time. We build the index when you store the email. We've done it once and then we we catch the result. Cube or sync is built on top of a high performance key value store. It's called LMDB. I don't know whether you've heard of it. It's a key value store that supports a single writer multi-reader semantics. So we have the resource process as the single writer in the system and all clients as the readers. So one client is certainly cube another could be an applet that listens for new mail sources something. But what that gives us is in-process access to the data. So if you start cube you wouldn't have to you wouldn't have to start any any other processes. The resource processes are not necessary for read-only access. You only need those processes if you actually want to get updates from your server. So if you start cube it just LMDB is just a memory mapped file essentially or the database is just a memory mapped file. So if you start cube it will just memory map the database into the process and then you can get to the data directly in process which makes it very fast and also allows you to do things like recursive queries without the real penalty because you have the data directly available in process and it leaves it delegates the complexity of for instance loading more data and making sure that that is fast to the file system. Yeah so that helps us also to to write more straightforward code. Last but not least is deployment and maintenance. If we want to do large large deployments of cube we have to have proper support for it to make it as easy as possible to do these kinds of setups. One example for for this focus is SyncShell which is a little command line utility that allows you to do things like setting up accounts for a user and modifying them removing them but also synchronizing them for instance synchronizing a certain set of folders and the command line utility will block until the synchronization is complete so you can put it into a script and run it through for for multiple users if you want but it also allows you to do things like carrying the local store and even modifying basically all objects so you can access the the full API that the application also has available. It even allows you to run it as a script interpreter and then it's you can write SyncShell scripts and it has a little ripple as addition but that's nice to have. The other important point is definitely a clean separation between configuration and data what that means that the configuration contains for instance your accounts that you have set up but everything you download from your from the group or server that is data so you should be at should be able at any point in time essentially to delete the data and the only thing that happens is that you have to pull the data again down from the server but that makes sure for instance if you have profile synchronization in a in a corporate setup that you can have the the configuration files under the profile synchronization and you can keep the data on the local machine and if you switch to another machine you may have to download some data again from the server but that's about it. Last but not least we have a configurable logging that you can tune the log levels with SyncShell because we don't want to go the approach that you that people compile out the logging output and then we have to provide custom binaries if there is a problem and so we'd rather have proper logging support that we then can also integrate with for instance journal D or whatever that the system supports. Yeah I think now is a very good time to join this project over the last year we've pretty much figured out the architecture and are quite happy where it's going so we can now start to scale this up a bit more. Sync is a very interesting modern C++ co-pays and so if you're interested in algorithms and performance work and that kind of stuff then Sync is very interesting but it's probably a more advanced co-pays on the cube side it's a lot easier or the whole UI is written in QML so there's a lot of that there's a lot of design work and then there are some models and controllers that are written in C++ but that's very straightforward but we also need help with things like cross-platform builds so we unfortunately didn't get to do build some Mac and Windows and Android so that's all stuff that we should get going but lack the manpower right now we do have weekly online meetings that are open to anyone that would like to join just write an email write an email to the mailing list and otherwise you can find more information on cube.kd.org I've just packaged an early tech preview for Fedora 25 it's mostly right now it's mostly for me to make sure that we actually can package everything and that it works as it should it's not meant at all for end users to do anything useful but you're welcome to try it and see what's what and follow it along that information is also on the home page of course and we'll update this with more up-to-date information as we go along we plan to release a or tag a tech preview within the next couple of weeks but that will still be for for development so for for end users it's going to be more towards end of the year for something actually end user ready we also built a flatback already together with Alish if you've seen his talk it's in the same repository as all other KDE applications it's not automatically updated yet but eventually we'll get like nightly builds for that and you can of course build it from source yourself if you feel like it yeah with that we can do we still have time then we can do a short demo oh no so yeah it's a bit interesting on a small screen like that but yeah on the right we have like a conversation view for emails we can uh that's for instance an encrypted message we can render some HTML spam we can switch accounts like this right now and yeah there's a composer that you can send an email from and you can move some emails and you can mark us right but it's not ready for for consumption really but yeah if I click here on a folder we always issue a query directly to storage we don't cache anything or so which again helps a lot with the complexity that we don't have to do that yeah with that we come to the questions we're not seeking to read the question the question was whether the intention is to replace contact we do not intend to replace contact there are many happy users of contact there's a team supporting continuing to support contact for call up systems this will be the successor for our use of contact so contact is our current desktop client you will be the successor for it and we believe we believe it's more more suitable for for our use case but I think it's it's really a different target audience contact has an incredible amount of great features that that work for a lot of people and we believe we want to build a simpler product that has a bit more more focus I'd say essentially the same system but it looks quite similar to a canadi so why do you write different how is different from a canadi I'm well so the quest the question was whether well the same question for a canadi whether I'm seeking to replace a canadi the answer is pretty much the same I have or I'm maintaining contact professionally for a call up systems so I I'm quite familiar with the whole system and I was obviously heavily inspired by by our canadi and and contact as well but I I believe that our canadi as it is is too complex and I believe this system improves upon a some some pain points if you will that that I've seen with a canadi so that's that's my my try for an improvement upon that so so why not improve a canadi why writing from scratch essentially because it's easier so the question was whether we would have exchange support the answer is I don't know it's certainly not an initial focus we are perfectly open to any contributions really yeah but I mean the there's there's nothing in principle from keeping us from having exchange support so the question was whether the only viable way is to use active think and that you would need a license for that and I don't know I'm so the answer would be EWS apparently