[Kde-pim] MailTransport resource capability

[Krzysztof Nowicki]

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).

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.

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.

Chris

> 
> 
> Dan
> 
> >What do you think?
> >
> >K.
> >_______________________________________________
> >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/
> 
> --
> Daniel Vrátil
> www.dvratil.cz | me at dvratil.cz
> facebook.com/danvratil | @danvratil | +DanVrátil
> _______________________________________________
> 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/


_______________________________________________
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/