Elepffwdsff

korsygfhrtzangaiide Elepffwdsff

rpc.php in horde's main directory is the starting point for our (and any)
RPC call.

It determines the $serverType ("syncml" for us) and then does something
like this:

$server = Horde_RPC::factory($serverType); // [will include RPC/syncml.php and create the class therein]
$server->authorize();
$input = $server->getInput(); // [basically the HTTP POST data]
$out = $server->getResponse($input, $params);
echo $out

So the main part takes place in getResponse of
framework/RPC/RPC/syncml.php's Horde_RPC_syncml class and there in
getResponse:

First, XML_WBXML_ContentHandler is installed as an output content handler:

$this->output = new XML_WBXML_ContentHandler();

Despite the name, this class has (almost) nothing to do with WBXML.
It's a helper to produce xml. To do this, it has 4 main methods:

1) startElement($uri, $element, $attrs) produces an <$element xlmns=$uri
   attr1=v1 ...> opening tag
2) characters($str) addes $str to the content
3) endElement($uri, $element) produces a closing tag </$element>
4) getOutput() returns the output produced so far

All subsequent code produces output by calling functions 1)-3)

After installing the output content handler, Horde_RPC_syncml::getResponse
continues with

$this->_parse($request);

do do the actual parsing and output creation and then finally

$xmlinput = $this->output->getOutput();

to retrieve the created output from the content handler.
The name $xmlinput is misleading, it should be called xmloutput instead.

So our quest for the code continues withing the Horde_RPC_syncml's _parse
function:

It creates an XML Parser and registers the class (well, the object) itself
as element handlers:
_startElement,_endElement, and _characters, which only format the data a
bit and call startElement,endElement, and characters respectively.

Please note, that start/endElment sounding functions are used for processing
the input as well as for creation of the output.
This can be somewhat confusing. As a rule of thumb, code that produces xml
output contains reference to an output var and looks like this:

$this->output->startElement(...);

After the XML parser is istalled, it is fired and the execution takes place
in the element handler functions.

A syncml message (input as well as output) has this structure::

<SyncML>
    <SyncHdr>
      ...stuff...
    </SyncHdr>
    <SyncBody>
      ...stuff...
    </SyncBody>
  <SyncML>

the content handler in Horde_RPC_syncml delegate the work for header and
body to the two sub-content handlers SyncML_SyncMLHdr and
SyncML_SyncMLBody which reside in framework/SyncML/SyncML.php.
So at least we made it to the to the SyncML package by now...

The job of SyncML_SyncMLHdr is to read all the values in the header
and store them in a php session (custom session, not normal horde session
system) of type SyncML_State. After all header data is collected,
outputSyncHdr write a SyncHdr as output.

SyncML_SyncMLBody is another delegator. First it creates a
SyncML_Command_Status to output the status-code of the session
(authorized or not).
The content of the <syncBody> element are command(-tags): for each element
in there, an appropriate handler is created with
SyncML_Command::factory($element);
and assigned the tasks of handling this command.
So execution continues with classes in SyncML/Command/ which are
all children of SyncML_Command.

>From here, you're on your own. Just two more facts:

1)
processing of changes received from the client are handled in
SyncML/Sync.php (not to be confused with SyncML/Command/Sync.php) and
there in runSyncCommand($command) command is one of
SyncML_Command_Sync_(Add|Delete|Replace)

2)
The other way around:
creating changes on the server for the client is done after the changes
from the client have been processed. This is done in TwoWaySync.php.
Some care has to be taken to avoid that the changes that are received
from the client are considered "new changes" and echoed back to the
client. That would result in severe data duplication meltdown.