Sink/Kube: 2 questions

[Christian Mollekopf]

On Fri, Mar 10, 2017, at 10:15 AM, René J. V. Bertin wrote:
> Christian Mollekopf wrote:
> 
> > master get's updated with every new release, so that'd be every 1-2
> > months. How unstable develop really get's I can't tell but
> > wer're certainly not making any guarantees. Right now nothing is in a
> 
> I've had my first success running kube yesterday, after I realised that
> it needs 
> Kirigami and not Kirigami*2* which is what you get if you install that
> package 
> from git/master ... I could set up my gmail account, got the folder list,
> but never saw a single message though apparently at least part of them was 
> downloaded when I quit kube (about 1/6th).

hmm.. ok. You could try "sinksh list mail" to see which mails you have
available locally.
("sinksh count mail" would just give you a count instead)

> The Mac build doesn't run because OS X tends to record full rpaths in
> shared 
> libraries, not just where libraries should be looked for, but also for
> libraries 
> where they should be loaded from (the so-called "id"). And that
> information 
> isn't consistent in the shared libraries stored under Qt's QML dir: they
> contain 
> rpath information to the standard library location (/opt/local/lib in my
> case).
> 
> Maybe they ought to be built as "modules" (CMake terminology) but then
> you 
> cannot use them anymore to link against. The best way would be to figure
> out how 
> to record the correct rpath information. This can be done post-hoc with a 
> special editing tool but there are a few too many of those libraries that
> each depend on a few too many siblings to make this appealing even for testing 
> purposes.

So what can we do to the buildsystem so it works on mac as well?

> And there's something else that's a real blocker for me if confirmed: I
> saw that email passwords are stored in clear in multiple files. I'm afraid I won't
> be using Kube as long as that cannot be avoided.
> 

Yeah, that's an open todo: https://phabricator.kde.org/T3657
It's a bit of a PITA because we need a cross-platform solution (so not
just kwallet).
qtkeychain would be an option or we build our own abstraction that
interacts with the native keychain systems.

> And to be honest, I'm also not particularly interested in an email client
> that 
> caches the full email collection locally, and would do so even for email
> I archive myself using a local IMAP server. I quit using Apple's Mail.app
> for that 
> same reason. Maybe I missed a configuration dialog somewhere that allows
> to configure this kind of detail?

Soooo... what are you interested in?
The current synchronization algorithm does the following:
* For any folder that is synchronized:
** Fetch the full payload for the last two weeks of data
** Fetch the headers for all messages in the folder

We currently lack configuration for that two week timeframe, but that
will be added eventually.
We could also add a second timeframe for which to get headers only, so
you don't have to get those at all.

Cheers,
Christian