Class Horde_SyncMl_Device
The Horde_SyncMl_Device:: class provides functionality that is potentially
(client) device dependant.
If a sync client needs any kind of special conversion of the data sent to it
or received from it, this is done here. There are two sources of information
to identify an device: The first (and better) one is the DevInf device info
sent by the device during a request. If DevInf is not supported or sent by
the client, the Source/LocURI of the device request might be sufficent to
identify it.
Copyright 2005-2012 Horde LLC (http://www.horde.org/)
See the enclosed file COPYING for license information (LGPL). If you
did not receive this file, see http://www.horde.org/licenses/lgpl21.
Methods summary
public
Horde_SyncMl_Device
|
#
factory( string $driver )
Attempts to return a concrete Horde_SyncMl_Device instance based on $driver.
Attempts to return a concrete Horde_SyncMl_Device instance based on $driver.
Parameters
- $driver
- <p>The type of concrete Horde_SyncMl_Device subclass to
return.</p>
Returns
|
public
string
|
#
getPreferredContentType( string $database )
Returns the guessed content type for a database URI.
Returns the guessed content type for a database URI.
When a client sends data during a sync but does not provide information
about the MIME content type with this individual item, this function
returns the content type the item is supposed to be in.
Parameters
- $database
- A database URI.
Returns
string
A MIME type that might match the database URI.
|
public
|
#
getPreferredContentTypeClient( string $serverSyncURI, string $sourceSyncURI )
Returns the preferrred MIME content type of the client for the given
sync data type (contacts/tasks/notes/calendar).
Returns the preferrred MIME content type of the client for the given
sync data type (contacts/tasks/notes/calendar).
The result is passed as an option to the backend export functions.
This is not the content type ultimately passed to the client but rather
the content type presented to the backend export functions.
After the data is retrieved from the backend, convertServer2Client()
can do some post-processing and set the correct content type acceptable
for the client if necessary.
The default implementation tries to extract the content type from the
device info. If this does not work, some defaults are used.
If the client does not provice proper DevInf data, this public function may
have to be overwritten to return the correct values.
Parameters
- $serverSyncURI
- <p>The URI for the server database: contacts,
notes, calendar or tasks.</p>
- $sourceSyncURI
- <p>The URI for the client database. This is
needed as the DevInf is grouped by
sourceSyncURIs.</p>
|
public
array
|
#
convertClient2Server( string $content, string $contentType )
Converts the content received from the client for the backend.
Converts the content received from the client for the backend.
Currently strips UID (primary key) information as client and server
might use different ones.
Charset conversions might be added here too.
Parameters
- $content
- The content to convert.
- $contentType
- The content type of the content.
Returns
arrayTwo-element array with the converted content and the
(possibly changed) new content type.
|
public
array
|
#
convertServer2Client( string $content, string $contentType, string $database )
Converts the content from the backend to a format suitable for the
client device.
Converts the content from the backend to a format suitable for the
client device.
Strips the UID (primary key) information as client and server might use
different ones.
Charset conversions might be added here too.
Parameters
- $content
- The content to convert
- $contentType
- <p>The content type of content as returned
from the backend</p>
- $database
- The server database URI.
Returns
arrayThree-element array with the converted content, the
(possibly changed) new content type, and encoding type
(like b64 as used by Funambol).
|
public
boolean
|
#
handleTasksInCalendar( )
Returns whether the device handles tasks and events in a single
"calendar" sync.
Returns whether the device handles tasks and events in a single
"calendar" sync.
This requires special actions on our side as we store this in different
backend databases.
Returns
booleanTrue if tasks and events are processed in a single
request.
|
public
boolean
|
#
omitIndividualSyncStatus( )
Returns whether to send individual status response for each Add, Delete
and Replace.
Returns whether to send individual status response for each Add, Delete
and Replace.
Returns
boolean
False if individual status responses should be send.
|
public
boolean
|
#
useCdataTag( )
Returns whether the payload data should be enclosed in a [CDATA[
section when sending via XML.
Returns whether the payload data should be enclosed in a [CDATA[
section when sending via XML.
The synchronized data may contain XML special characters like &,
< or >. Clients might choke when sending these embedded in XML.
The data should be enclosed in [CDATA[ in these cases. This applies
only to XML, not to WBXML devices.
Returns
boolean
True if the data should be enclosed in [CDATA[.
|
public
boolean
|
#
useLocalTime( )
Returns whether the device accepts datetimes only in local time format
(DTSTART:20061222T130000) instead of the more robust UTC time
(DTSTART:20061222T110000Z).
Returns whether the device accepts datetimes only in local time format
(DTSTART:20061222T130000) instead of the more robust UTC time
(DTSTART:20061222T110000Z).
Returns
boolean
True if the client doesn't accept UTC datetimes.
|
Properties summary
public
string
|
$requestedContentType
The original preferred content type of the client, if provided through
DevInf.
The original preferred content type of the client, if provided through
DevInf.
|
|