Re: Fixing things Akonadi doesn't with some SQL-fu

Daniel Vrátil <[email protected]> Thu, 22 Mar 2018 14:19:05 +0100
Newsgroups	gmane.comp.kde.users.pim
Organization	KDE
Message-ID	<1895515.ELReh1g3DH@mjollnir>
On Thursday, 22 March 2018 12:36:48 CET René J.V. Bertin wrote:
> 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, 

Not neccesarily. On mobile you usually only have a single mail account, maybe 
a calendar and you keep around only limited history, so the memory impact is 
smaller in general. Whether you have 5 processes using less memory each or one 
process using more memory does not really matter. And of course an opportunity 
to make Akonadi less memory-hungry in general (although I'm amazed that people 
complain about Akonadi using couple hundred megs of memory, but are completely 
OK with shitty Electron-based desktop apps using half a gig of RAM each).

Assuming Android, I can imagine having Akonadi Server+agents as a single 
process that performs background syncs and a separate GUI process that talks 
to it.

> but wouldn't it also remove whatever bottleneck
> there is currently because of interprocess communications?

Our IPC is extremely fast these days, usually the slowest part is the database 
right now, which we are working on with Pablo.

> >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?;)

Well, I'm not porting Akonadi away from DBus just because Mac cannot get it 
right ;-)

> 
> R


-- 
Daniel Vrátil
www.dvratil.cz | [email protected]
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
signature.asc (application/pgp-signature, 833 B)