When I wrote the other day about the 8211 version of the MAPICDO download, I mentioned there a new notification flag. Here’s more information on that flag.
The new flag is fnevLongTermEntryIDs: #define fnevLongTermEntryIDs ((ULONG) 0x20000000)
This flag is not a new notification type and should not be used on its own. Instead, pass this flag in the uLEventMask parameter of IMsgStore::Advise to change the way fnevNewMail and the various fnevObject* notifications behave. Normally, when you get these notifications from the Exchange provider, the NEWMAIL_NOTIFICATION and OBJECT_NOTIFICATION structures contain Short-Term Entry IDs. With the addition of this flag, these will be Long-Term Entry IDs.
We added this flag to help with a common performance issue: MAPI clients which are tracking changes to messages will typically index their current view of messages by the Long-Term Entry ID. When they get a notification that an item has changed, they would call OpenEntry to open the item and from there request the Long-Term Entry ID so they can match the notification to the item in their index. They’d have to do this even if they don’t need any other properties from the message. These repeated OpenEntry calls can be expensive. By implementing the fnevLongTermEntryIDs flag, we’re giving them a way to avoid most of these calls.
Even if the long term Entry IDs are returned by the notification, isn't the CompareIDs method is still needed to match the notification to an item? If so, is there a benefit to this approach compared to using CompareIDs on a short term Entry ID from a notification to a list of long term Entry IDs in an index?
Certainly, you could do that. Some applications want to queue the notifications as they come in and defer processing until later (or even hand it off to another process). This can make using Short-Term Entry IDs difficult since they may no longer be valid when you get around to processing them.
This is most welcome Steve! Currently we have to maintain a list of long term ids and use a table notification to process messages that are deleted. This is because with a short term id you can't open the entry to get its long term id (as its been deleted!). As we use the long term id to link entries in our system and exchange, this will be of huge benifit to us as we will no longer need to maintain this list. Or so I hope anyway.