Fixing things Akonadi doesn't with some SQL-fu

René J.V. Bertin rjvbertin at gmail.com
Thu Mar 22 11:36:48 GMT 2018


On Thursday March 22 2018 11:58:18 Daniel Vrátil wrote:

> having the whole thing run as a single-process application is
> certainly possible and would not require any changes in the existing
> architecture.

I guess that would increase the memory footprint of that single process by a few orders of magnitude, but wouldn't it also remove whatever bottleneck there is currently because of interprocess communications?

>I don't know how Mac bundles exactly work at runtime, but I suppose that as 

Nothing special, everything is simply set up such that required resources are found inside the bundle (which is just a directory structure). The dynamic linker/loader does have a few mods to make it possible to move the bundles around freely (think relative rpath entries) and there are SDK functions for finding an app bundle, its info dict etc. But basically you can achieve the same thing under Linux - GNUStep does for instance.

That also means everything doesn't have to be inside the app bundle; the minimum is the binary and an info dict (Info.plist) that informs the system what and how to do with the bundle in order to launch it.

>long as other apps can access the same DBus session as the Kontact.app bundle 

That's probably the main hurdle. All-encompassing, standalone means everyone includes and runs their DBus, so this approach will only allow independent applications (or application suites) that cannot talk among each other via DBUS.

So yeah, it's possible, but at the very least it'd need an independent DBus install if that's the only interface through which interaction with other applications takes place.
FWIW, the current KDEPIM4 implementation in MacPorts uses a standard Unix way of installing stuff using a minimal app bundle for the front-ends and everything else installed in traditional fashion under a $prefix where all dependencies are also installed. That's also how I'd implement the KDEPIM5 ports.

>interaction, then it's hardly something you can blame Kontact or Akonadi 
>architecture for.

I'm not sure "blame" is the appropriate term, whom else could I "blame" for the fact that Kontact/Akonadi chose to use DBus instead of something else?;)

R



More information about the kdepim-users mailing list