Transducers

Transducers are objects whose purpose is to convert (transduce) a thing from one representation to another. We deal with five sorts of 'thing' from this point of view, namely Calls, Contacts, Emails, Meetings and Tasks. However, while Calls and Meetings are different sorts of thing at the CRM side, they're instantiated as only one sort of thing, Appointments, on the Outlook side.

Therefore for each of Contacts, Emails and Tasks we need two transducers - and Outlook-to-CRM transducer and a CRM-to-Outlook transducer.

For Calls and Meetings we have to determine which Appointments should be synchronised as Calls and which as Meetings. We could do that in a single Outlook-to-CRM transducer for Appointments, but it seems to me that it makes more sense to have separate wrapper classes for Calls and Meetings (each class wrapping an outlook AppointmentItem) and also to have two transducers for each of Calls and Meetings as well, making ten transducers in total (plus probably two abstract superclasses).

Appropriate language

Writing JSON packets in C# is incredibly prolix, at least the way it is done in Version 3. Consequently, transduction in version 3 require 42 separate classes (virtually the whole of the SuiteCRMClient package and substantial code in the Synchroniser classes in SuiteCRMAddIn) and thousands of lines of code. To write it in Clojure CLR would be enormously cleaner and simpler. It's possible that to write it in dynamic C# would have a similar degree of cleanliness. Both approaches are worth evaluating.

While I know that Andrew did a great deal of work on SuiteCRMClient and cleaned it up enormously, there are still parts of it which are messy and opaque. If by switching to dynamic objects or Clojure we could do away with the vast bulk of it altogether, I believe that would be a win.

If Clojure CLR is chosen, this appears to be the appropriate JSON library.