<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

  <head>

    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

    <title></title>

  </head>

  <body bgcolor="#ffffff" text="#000000">

    <br>

    <span style="white-space: pre;">> IMHO Riccardo has a good point.

      At the cost of java dependency we <br>

      > could bring the whole SyncML infrastructure in right now.

      This might<br>

      > be as an optional app that can be disabled if the target

      system <br>

      > lacks support, so the integrity of remaining features is not

      <br>

      > compromised.</span><br>

    <br>

    One question which has not been answered is what are the advantages

    of SyncML versus other protocol?<br>

    It was only said that this was a standard with lot of existing

    clients... from the wikipedia page (i know this is not a reference),

    i get:<br>

     * A fairly intricate and vague protocol specification has meant

    that in general there are major interworking problems with different

    servers against different clients<br>

     * SyncML requires a /database name/ to be specified for opening a

    connection. This database name is not standardized, and different

    servers use different names for the same service<br>

     * According to the documentation in the Funambol SyncML wiki, there

    is no conflict resolution. The server can only be set to 'client

    wins' or 'server wins' in case a field has been edited both on

    server and on client.<br>

    <br>

    This does not seems very interesting. A complex and incomplete

    standard is worst than a simple well defined one. Especially if

    there is no good php implementation (and KDE does not support

    SynML?). But maybe this is wrong (since it is from wikipedia). So

    why push so much in favor of syncml?<br>

    <br>

    regards,<br>

    Cédric<br>

  </body>

</html>