kdepim-runtime does not provide imap kio slave
Closed, WontfixPublic

Description

In KDE4 times it was possible to access imap or pop3 servers using the imap or pop3 kioslave included in kdepimlibs repo. With the migration to kf5 the pop3 kioslave plugin has landed in the kdepim-runtime repo (https://cgit.kde.org/kdepim-runtime.git/tree/kioslave), but the imap kioslave plugin is unfortunately no longer available, but is needed to realize https://bugs.kde.org/show_bug.cgi?id=399094

habacker created this task.Sep 27 2018, 6:54 AM
dvratil closed this task as Wontfix.Sep 27 2018, 8:08 AM
dvratil claimed this task.
dvratil added a subscriber: dvratil.

The IMAP slave has been removed intentionally during migration to KF5. Please use the KIMAP library to interact with IMAP servers.

knauss added a subscriber: knauss.Sep 27 2018, 8:20 AM

And the mail:/ kio interface may be interesting for this task:

"You can then open «mail:/» in dolphin or whatever to browse your email
attachments."

for more details see: https://marc.info/?l=kde-pim&m=153772379115909&w=2

dvratil added a comment.EditedSep 27 2018, 8:40 AM

However, unlike the IMAP slave, the kiomail requires users to use Akonadi and have their email accounts configured there - at which point interfacing with Akonadi directly might more optimal :-)

"You can then open «mail:/» in dolphin or whatever to browse your email attachments."

Do not work here because I'm not using akonadi/kmail

The IMAP slave has been removed intentionally during migration to KF5.

What is the reason why the imap kioslave was removed? pop3 has similar functionalities and was not removed.

Because it was no longer needed (fully replaced by Akonadi and IMAP resource), it was duplicating a lots of code from KIMAP library and no-one was interested in porting it and maintaining it.

POP3 hasn't been removed because we don't have a replacement yet. While mapping IMAP onto an IO slave somewhat works, POP3 is mostly an abuse of the IO slave API and I hope to kill it as well at some point.

If you want the IMAP IO Slave, you are welcome to port it to KF5 and maintain it in KMyMoney, but we really don't have the time or manpower to maintain another IMAP implementation (one is causing us enough pain as it is).

Because it was no longer needed (fully replaced by Akonadi and IMAP resource

At the cost of no longer available imap kio slave support

it was duplicating a lots of code from KIMAP library

then it looks to be the best to refactor the kimap kio plugin to use the KIMAP library and let the plugin only be a thin wrapper providing the kio slave protocol.

we really don't have the time or manpower to maintain another IMAP implementation (one is causing us enough pain as it is).

This I can understand and is an additional argument inside the imap kio plugin to use the KIMAP library

Any chance to make this a GSOC task ?

We don't really participate in GSOC/SOC/etc.. I don't want to speak for @mlaurent, but from my side, we simply don't have the time and manpower to manage it. And the topic of GSOC and similar projects never even came up on any PIM meeting.

If KMyMoney can coach a GSOC, we can for sure provide some guidance (on the technical level) to help with finishing the port, but I can say for sure that we are not willing to maintain the port.