---- Reported by jingke.zhang@intel.com 2010-04-13 20:37:32 +0000 ----

This is from http://bugzilla.moblin.org/show_bug.cgi?id=9446

   Description  From  pohly   2010-02-03 23:30:16 PST   (-) [reply]

In 1.0, "syncURL" was redefined as list of urls. This has two purposes:
- identified peers contacting us even when they switch between
  different Bluetooth MAC addresses
- support a peer which can be contacted in different ways

The first point works, the second doesn't. Right now, the code in
SyncContext::getUsedSyncURL() always picks HTTP as transport if HTTP is
supported. This code and the higher levels need to become more intelligent and
pick transports which can succeed (presence) and iterate through them if that
choice fails.

------- Comment #1 From pohly 2010-02-04 00:29:24 PST (-) [reply] -------

I updated the syncURL help text:

$ src/syncevolution --sync-property syncURL=?
'--sync-property syncURL=?'
   Identifies how to contact the peer,
   best explained with some examples:
   HTTP(S) SyncML servers:
     http://my.funambol.com/sync
     http://sync.scheduleworld.com/funambol/ds
     https://m.google.com/syncml
   OBEX over Bluetooth uses the MAC address, with
   the channel chosen automatically:
     obex-bt://00:0A:94:03:F3:7E
   If the automatism fails, the channel can also be specified:
     obex-bt://00:0A:94:03:F3:7E+16
   For peers contacting us via Bluetooth, the MAC address is
   used to identify it before the sync starts. Multiple
   urls can be specified in one syncURL property:
     obex-bt://00:0A:94:03:F3:7E obex-bt://00:01:02:03:04:05
   In the future this might be used to contact the peer
   via one of several transports; right now, only the first
   one is tried.

Congwu, is this okay? In "pohly" branch.



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 723 at https://bugs.meego.com/show_bug.cgi?id=723