Kube is a next generation communication and collaboration client, built with QtQuick on top of a high performance, low resource usage core called Sink.
It provides online and offline access to all your mail, contacts, calendars, notes, todo’s etc.
Kube has a strong focus on usability and the team works with designers and Ux experts from the ground up, to build a product that is not only visually appealing but also a joy to use.
To learn more about Kube, please see here.
Kube’s Account System
Kube is a network application at its core. That doesn’t mean you can’t use it without network (even permanently), but you’d severely limit its capabilities given that it’s meant to be a communication and collaboration tool.
Since network communication typically happens over a variety of services where you have a personal account, an account provides a good starting point for our domain model. If you have a system with large amounts of data that are constantly changing it’s vital to have a clear understanding of data ownership within the system. In Kube, this is always an account.
By putting the account front and center we ensure that we don’t have any data that just belongs to the system as a whole. This is important because it becomes very complex to work with data that “belongs to everyone” once we try to synchronize that data with various backends. If we modify a dataset should that replicate to all copies of it? What if one backend already deleted that record? Would that mean we also have to remove it from the other services?
And what if we have a second client that has a different set of account connected?
If we ensure that we always only have a single owner, we can avoid all those issues and build a more reliable and predictable system.
The various views can of course still correlate data across accounts where useful, e.g. to show a single person entry instead of one contact per addressbook, but they then also have to make sure that it is clear what happens if you go and modfiy e.g. the address of that person (Do we modify all copies in all accounts? What happens if one copy goes out of sync again because you used the webinterface?).
Last but not least we ensure this way that we have a clear path to synchronize all data to a backend eventually, even if we can’t do so immediately. E.g. because the backend in use does not support that data type yet.
The only bit of data that is stored outside of the account is data specific to the device in use, such as configuration data for the application itself. Data that isn’t hard to recreate, is easy to migrate and backup, and very little data in the first place.
Most services provide you with a variety of data for an individual account. Whether you use Kolabnow, Google or a set of local Maildirs and ICal files,
you typically have access to Contact, Mails, Events, Todos and many more. Fortunately most services provide access to most data through open protocols,
but unfortunately we often end up in a situation where we need a variety of protocols to get to all data.
Within Sink we call each backend a “Resource”. A resource typically has a process to synchronize data to an offline cache, and then makes that data accessible through a standardized interface. This ensures that even if one resource synchronizes email over IMAP and another just gathers it from a local Maildir,
the data is accessible to the application through the same interface.
Because various accounts use various combinations of protocols, accounts can mix and match various resources to provide access to all data they have.
A Kolab account for instance, could combine an IMAP resource for email, a CALDAV resource for calendars and CARDDAV resource for contacts, plus any additional resources for instant messaging, notes, … you get the idea. Alternatively we could decide to get to all data over JMAP (a potential IMAP successor with support for more datatypes than just email) and thus implement a JMAP resource instead (which again could be reused by other accounts with the same requirements).
While accounts within Sink are mostly an assembly of some resources with some extra configuration, on the Kube side a QML plugin is used (we’re using KPackage for that) to define the configuration UI for the account. Because accounts are ideally just an assembly of a couple of existing Sink resources with a QML file to define the configuration UI, it becomes very cheap to create account plugins specific to a service. So while a generic IMAP account settings page could look like this:
… a Kolabnow setup page could look like this (and this already includes the setup of all resources including IMAP, CALDAV, CARDDAV, etc.):
Because we can build all we know about the service directly into that UI, the user is optimally supported and all that is left ideally, are the credentials.
In the end the aim of this setup is that a user first starting Kube selects the service(s) he uses, enters his credentials and he’s good to go.
In a corporate setup, login and service can of course be preconfigured, so all that is left is whatever is used for authentication (such as a password).
By ensuring all data lives under the account we ensure no data ends up in limbo with unclear ownership, so all your devices have the same dataset available, and connecting a new devices is a matter of entering credentials.
This also helps simplifying backup, migration and various deployment scenarios.
12 thoughts on “Kube: Accounts”
Isn’t there a large overlap between Kube and Akonadi?
The data backend for Kube is a replace for Akonadi focused on performance, simplicity, and reliability. Kube itself looks to replace the UI (though not all the internal business logic) of Kontact. HTH.
Sorry, I don’t understand much.
So, what is an account ?
Let’s say I have three email addresses. Do I have to set up one account or three, or something else ?
What “records” are shared between multiple backends ?
Beside that, I hope it’s still way simpler and faster than Akonadi ?
“Do I have to set up one account or three, or something else ?”
One for each account (so in your example: 3). This is the “human” definition of an account, however. Some accounts may actually set up quite a few things behind the scenes (e.g. storage for mail, calendars, etc..) but to us humans using the system it looks just like that one account we have from our provider.
“What “records” are shared between multiple backends ?”
This would be things like which server addresses to use. But this is completely transparent to the end user, and as far as the user is concerned each account is just One Thing. That is uses multiple protocols and mechanisms behind the scenes is not exposed nor relevant to the user.
“I hope it’s still way simpler and faster than Akonadi ?”
Yes, and if you look at the concept of an “acocunt” in Akonadi, you’ll see it doesn’t really have one. Use the account wizard to set up a Kolab account and then look in the config dialogs afterwards … you’ll see it has created an IMAP account, an SMTP account, calendars, contacts … … and none of them are really connected with each other. The account wizard just goes around creating a ton of separate configurations in Akonadi (and that gets reflected in Kontact). So it is very, very easy to mess up your “Kolab account” by just mucking with the wrong config dialog since there actually is no proper concept of a “Kolab account” in Akonadi in the same fashion that Kube’s storage layer provides.
We’re using Kolab in our business. Is it possible to consider using Kube as a Frontend on some machines while continuing to use akonadi/kontact on others plus some places where roundcube is used? I understood Kube/sink is not yet ready for production use. Is there any alpha/beta/preview to test it?
It will be possible to use Kube with other clients in parallel, yes. Unfortunately we’re not yet in the stage where we have something for users to test. A first release is planned for beginning of next year though.
Is Kube a Gnome application or why does it use such CSD headerbars?
It’s not a “gnome application” although it will work on gnome just as well as on any other DE. We’re currently experimenting with various ways to display the settings, so I guess thats what you mean by CSD.
CSD = Client Side Decorations, i.e. title bars are not drawn by the window manager but instead disable them and put Back buttons where the title bar belongs.
Having used gedit on gnome recently. I don’t see any advantage in moving Ok/Cancel buttons from the place where they always have been on all platforms (at the bottom of the dialog) to the topof the dialog.
JMAP please 🙂
Also thank you “Kube” guys, thanks to you I found JMAP, very interesting. I really hope Dovecot will come with JMAP support soon..
Yes, but the Kolab Server doesn’t currently support it, but it will have to do when Kolab finally make good on their Roundcube Next plans.
I’m waiting to see how they plan to solve the fragmentation issues which have arisen on Kolab Server with separate *DAV protocols. Consolidation is overdue, but a major task.