Tasks

Tasks are simply tasks to be actioned by the scheduler.

In version 3, for each class of CRM object, we ran a periodic synchronisation sweep (every 5 minutes), touching every item of the specified type; and, additionally, when an item was changed on the Outlook side, we sent an immediate transmission.

An enormous amount of fragile Should code surrounds the decision whether and when to send that transmission; this is mainly because of Outlook event problems, but also, I believe, because the original author either had not the skill to fully implement the state transition engine, or, more probably, failed to communicate the design intention of the state transition engine to his successor.

If the state transition engine works properly, all the Should code can go. But also, given that we're doing a periodic synchronise task, there's no real need for TransmitNewAction, TransmitUpdateAction, or UpdateMeetingAcceptancesAction; all three can simply be handled in the periodic sweep.

Furthermore, there's no need for the periodic sweep to touch all records. We need to do such a sweep when that add-in starts up, to make sure we've got them all; but after that, we only need to touch those which have been modified since the last sweep.

So not only can we save a lot of code, we can also save a lot of work. This reduces the list of tasks to probably:

1. FetchEmailCategoriesAction
2. SyncAllAction
3. SyncSinceAction

where SyncAllAction is a thin subclass of SyncSinceAction.