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.


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to