On Wed, 2009-11-18 at 07:35 +0000, Chen Congwu wrote:
Why is getMimeType specific to SyncSourceSerialize?
Because it is only used for the Synthesis field list <-> serialized
backend format data conversion.
Any SyncSource should provide his preferred mime type, thus it looks
resonable to move it to SyncSource base class.
The preferred MIME type of a data source when talking to a SyncML server
is specified entirely in the configuration file, via the "type"
property. Internally this piece of information is available via
SourceType as returned by getSourceType().
If a backend wants to override this, it can do so. getSourceType() is a
virtual method in SyncSourceConfig, inherited by SyncSource.
While I am adding the contentType filed in the SAN message, I found
not a general way to get the format the backend is using, basically we need to:
check syncSourceType.m_backend if m_format is empty, this needs to match to a
bunch of backend predefined strings like "Evolution Addressbook", etc.
I am thinking using getMimeType for one stop solution but it is not a
method in SyncSource class at the moment.
What's your ideas on this? I would like to move it to the base class if no
I'd prefer not to change this. If there is a need, we could introduce an
additional getPeerMimeType() call in SyncSource which
Is the MIME type in the SAN message really needed by a peer? According
to the discussions with Synthesis, the usefulness of specifying it is
dubious because a) not all possible MIME types ("text/x-my-own-format")
can be represented in the binary format used in the SAN message anyway
and b) the URI also determines the format.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.