[Kde-pim] Exchange (MAPI) akonadi resource for calendar and GAL

[Shaheed Haque]

Hi Ribert,

Did you have a chance to test your proposed changes?

Separately, you'll see that I've just committed the refactor of the
Calendar to use the new MapiResource base. My next step is to port the GAL,
and get it working for me; my current expectation is that I'll need to get
incremental loading working to achieve that goal. I've currently no idea
what that will entail, but at least by centralising things, it will then
work for all resources.

Thanks, Shaheed

On 12 December 2011 13:26, Shaheed Haque <srhaque at theiet.org> wrote:

> Hi Robert,
>
> I saw your new code, and it certainly looks much simpler. I ran  few
> tests, and saw some interesting differences. For example, for one
> appointment involving only internal people your approach gave:
>
> number of recipients: 20
> recipient[ 0 ] type: 1 flags: 977 name: "Sindhu Payankulath (sindhu)"
> email: "Sindhu"
> recipient[ 1 ] type: 1 flags: 2001 name: "Sindhu Payankulath (sindhu)"
> email: "Sindhu"
> recipient[ 2 ] type: 1 flags: 2011 name: "staff.sindhu at cisco.com" email: "
> staff.sindhu at cisco.com"
> ...
> recipient[ 12 ] type: 1 flags: 2011 name: "group.benfa at cisco.com" email: "
> group.benfa at cisco.com"
>
> versus my old approach which had some duplicates:
>
> attendee name: "S##" email: "/O=##/OU=FIRST ADMINISTRATIVE
> GROUP/CN=RECIPIENTS/CN=S##"
> ...
> attendee name: "group.b###@###" email: "group.benfa@###"
> attendee name: "group.b##@###" email: "group.benfa@###"
> ...
> attendee name: "S### P### (s###)" email: "s###@###"
> ...
> attendee name: "staff.s###@###" email: "staff.s###@###"
> attendee name: "staff.s###@###" email: "staff.s###@###"
> ...
> attendees after resolution: 22
>
> The old approach clearly has a bug with duplicates which needs looking at,
> and also does not incorporate the interpretation of the x500 case. The
> first two entries in your logic also raises the interesting point about
> flags. Ideally we'd want to collapse them if the flags can be combined.
>
> I also noticed that your new approach definitely works better in the case
> of external participants, where the email is already fully resolved.
>
> The one case which the new approach does not seem to handle is one where
> the test logic get this:
>
> number of recipients: 1
> recipient[ 0 ] type: 1 flags: 977 name: "D### L### (d###)" email: "D###"
>
> against the old logic which finds one more entry:
>
> attendee name: "D### L### (d###)" email: "d###@###.###"
> attendee name: "Shaheedur Haque (s###)" email: "s###@###.###"
> attendees after resolution: 22
>
> Note, the extra name in this case is me, as I set up this meeting. My gut
> feeling is that if we can fix this issue, your new approach looks very
> promising. Especially if we can combine the flags in a useful manner (maybe
> OR'd). I'll look into that, but would welcome your thoughts too.
>
> Thanks, Shaheed
>
_______________________________________________
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/