It doesn't make sense to do the write automatically through the usual conversion service mechanism since it doesn't need to get written every event. On the contrary, it should get done only at the explicit request of user code. (Also, to read in a calibration actually involves a two-step conversion which can't readily be reversed for write. I'm just trying to reverse the 2nd part.)
Keep in mind that these files are much simpler than event data files. They will only consist of one large object, corresponding to a leaf in the TDS. That is, information is not indexed by event and there is no hierarchy of converters to correspond to hierarchical data in the TDS.
A typical calibration in the TDS, say calorimeter gains, is represented by a class with the following inheritance:
CalCalibGain >> CalCalibBase >> CalibBase >> DataObject
where >> means is derived from.
There is an analogous hierarchy of ROOT classes (in namespace calibRootData in the to-be-released package of the same name)
CalGainCol >> CalBase >> Base >> TObject
So, rephrased, the task is, upon user request, to take a CalCalibGain (or other calibration) object, create a CalGainCol (or other) ROOT object containing the "same" information, and write it to a physical ROOT file.