[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Exchange (MAPI) akonadi resource for calendar and GAL
From:       Shaheed Haque <srhaque () theiet ! org>
Date:       2011-12-12 13:26:50
Message-ID: CAHAc2jdEMdKsk_CQK4oqi4T=KetT6W+CtW9QfSTeaeNn4XEzaQ () mail ! gmail ! com
[Download RAW message or body]

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@cisco.com" email: "
staff.sindhu@cisco.com"
...
recipient[ 12 ] type: 1 flags: 2011 name: "group.benfa@cisco.com" email: "
group.benfa@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@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]