[Kde-pim] MailTransport resource capability

[Daniel Vrátil]

On February 24, 2016 10:06:55 PM GMT+01:00, Krzysztof Nowicki <krissn at op.pl> wrote:
>Dnia środa, 24 lutego 2016 08:54:31 CET Daniel Vrátil pisze:
>> On February 23, 2016 7:28:46 PM GMT+01:00, Krzysztof Nowicki
><krissn at op.pl> 
>wrote:
>> >Hi,
>Hi,
>
>> >
>> >I've stumbled upon another potential issue when working on the
>Akonadi
>> >EWS
>> >resource. In the Microsoft Exchange world there is no SMTP. Both
>> >receiving and
>> >sending e-mail happens through the EWS protocol. On the Akonadi side
>> >the
>> >default method to send e-mail is SMTP. Fortunately however a
>resource
>> >can
>> >declare the "MailTransport" capability, which will allow it to be
>used
>> >to send
>> >e-mail.
>> 
>> Remember that you need to reimplement TransportResourceBase for it to
>work.
>
>I know. That part is already implemented and working fine :)
>
>> 
>> >This is where things get complicated, as the "MailTransport"
>capability
>> >was
>> >designed to indicate a MTA-only resource. This means that declaring
>> >that
>> >capability on a resource will disable some email reception
>capabilities
>> >(no
>> >"Check mail" possibility for example)
>> 
>> <snip>
>> 
>> >So I was thinking if there would be a way to allow all-in-one
>resources
>> >in
>> >Akonadi. One possibility would be to lift the current restrictions
>as
>> >to
>> >receiving e-mail from resources with the "MailTransport" capability.
>> >This
>> >would however potentially break backward compatibility with
>resources
>> >that
>> >expect the current behaviour.
>> >
>> >An alternative would be to declare some additional capability
>> >("MailTransportReception"?) to indicate such all-in-one resources.
>> 
>> I don't recall any such restriction in Akonadi server or in the
>> TransportResourceBase, so I assume you ran into an artificial
>restriction
>> in KMail UI.
>> 
>> Introducing a new capability is a good idea, although I think it
>would be
>> better to just have a "Synchronizable" capability, explicitly saying
>that
>> this resource can sync. This way existing resources keep working
>(sync is
>> implicit), MailTransport-only agents will not have sync (MT
>capability
>> disables implicit sync), and you resource would have both, because
>you
>> would explicitly declare the sync capability. Will of course need
>some
>> adjustment in KMail to make it honor the new capability. Maybe the
>logic
>> could be implemented in some method in Akonadi libs, something like
>> Akonadi::AgentInstance::canSync().
>
>You're right here - it's a limitation of KMail not Akonadi itself.
>Having 
>looked at the code the problem is slightly more complicated from an 
>implementation point of view as it would require some hacking around 
>AgentFilterProxyModel (KMail uses it's exclude list to filter out MTA
>resources 
>from the list of receiving resources).

OK. I can't look at the implementation, but I assume it should still be rather simple to implement this, for you can implement this behavior directly in the model then. 

>
>Even if that is done KMail doesn't allow re-using an existing receiving
>
>resource as a send resource - it forces creation of a new resource
>instance 
>which is exactly what should be avoided.

Again I believe this is just an artificial limit in KMail - you can ask Laurent (here on IRC) to help you with this or point you in the right direction. 

>
>Since I'm close to the point I can release some usable Akonadi EWS
>version 
>I'll temporary go for a two-resource approach, but I hope to make an
>attempt 
>at fixing KMail by the time 16.04 is frozen.

If you are fine with not supporting < 16.04, I'd say don't bother (unless your current architecture makes the split supereasy) and just fix it in current PIM master :) Also make sure to blog about this (and add yourself to planet.kde.org), so that everyone know about your awesome work! 

I can help you with the adjustments in Akonadi next week when I'm back at my computer,until then email is all I have :) 

Dan


>
>Chris
>> 
>> Dan
>> 
>> >What do you think?
>> >
>> >K.

-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/