On Wed, 2009-11-18 at 07:35 +0000, Chen Congwu wrote:
Hi
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
more
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
there is
not a general way to get the format the backend is using, basically we need to:
getSyncSourceType
check syncSourceType.m_format
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
objection.
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.