In case it hasn’t become obvious by now, SyncBridge 1.0 is partially implemented using the RubyCocoa library (for all the usual reasons that one would choose Ruby over Objective-C). I’ve had to wrap the SyncServices API such that Ruby understands it (and I’ll be releasing that very soon as open source – Fuji-san is aware that I’m going to be doing that).
The single biggest issue that I had to debug was in type mismatches. SyncSchemas and Client Descriptions are what SyncServices use for determining what properties need syncing between clients, devices, servers, etc. These properties are specified using fairly generic names (“number”, “array”, “calendar date”) but they map directly to very specific Cocoa foundation types. RubyCocoa handles most of these just fine, but some aren’t quite right.
The two main culprits I’ve found so far are Fixnum and Date. A Fixnum gets translated to an Obj-C NSDecimalNumber, but SyncServices expects an NSNumber. Likewise, a Date becomes an NSDate, but SyncServices expects an NSCalendarDate.
Now for the really annoying part. SyncServices exception handling seems a bit spotty – when I passed a (RubyCocoa-converted) NSDate, it threw me an error that made it easy to see I needed to change the type of the variable (and SyncroSpector allowed me to determine which type). But when I pass an NSDecimalNumber instead of an NSNumber, the SyncServer didn’t throw any warning at all, it just didn’t update correctly (or at least this is the symptom I’m still seeing).
I’ll post more as I get to the bottom of this, possibly with a conversion table/script to make the SyncServices/RubyCocoa wrapper a bit more intuitive to use. It might be that RubyCocoa makes assumptions about types that I can override in the wrapper.