Menu
▾
▴
opensync-devel
|
From: Henrik /K. <kaa...@us...> - 2009-10-20 16:47:15
|
If I want to provide a static xml file with capabilities for my plugin instead of using osync_capability_new in code, what do I call the file and where do I put it? Also: is the correct root element in the XML <capabilities> as in xmlformat test cases or <Cap> as in the group files ? |
|
From: Daniel G. <go...@b1...> - 2009-10-20 21:16:27
|
On Tuesday 20 October 2009 06:47:00 pm Henrik /KaarPoSoft wrote:
> If I want to provide a static xml file with capabilities for my plugin
> instead of using osync_capability_new in code, what do I call the file
> and where do I put it?
$datadir/libopensync1/capabilities/
e.g. /usr/local/share/libopensync1/capabilities/
There is also a CMake variable you use to install to the correct path:
${OPENSYNC_CAPABILITIESDIR}
e.g. ${OPENSYNC_CAPABILITIESDIR}/mozilla-sync.xml
Beside this capabilities file, you need also to write a "description" file
which points/refers the filename of your capabilities file (e.g. mozilla-
sync.xml)
Example of such a descriptino file is:
trunk/misc/descriptions/syncml-nokia.xml
-----8<-----
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<versions version="0.1">
<version>
<PlugIn>SyncML</PlugIn>
<Priority>100</Priority>
<Vendor>Nokia</Vendor>
<ModelVersion>7650</ModelVersion>
<FirmwareVersion></FirmwareVersion>
<SoftwareVersion></SoftwareVersion>
<HardwareVersion></HardwareVersion>
<Identifier>syncml-nokia-7650.xml</Identifier>
</version>
</versions>
----->8-----
In your case:
-----8<-----
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<versions version="0.1">
<version>
<PlugIn>mozilla-sync</PlugIn>
<Priority>100</Priority>
<Vendor>Nokia</Vendor>
<ModelVersion></ModelVersion>
<FirmwareVersion></FirmwareVersion>
<SoftwareVersion></SoftwareVersion>
<HardwareVersion></HardwareVersion>
<Identifier>mozilla-sync.xml</Identifier>
</version>
</versions>
------>8----
Note that <Identifier> needs to be the filename (not the path!) of the
capabilities xml file.
place this as ... (again a cmake variable is available):
${OPENSYNC_DESCRIPTIONSDIR}/mozilla-sync.xml
there are even cmake macros to install the description and capabilites file
OPENSYNC_PLUGIN_DESCRIPTIONS( mozilla-sync-desc.xml )
OPENSYNC_PLUGIN_CAPABILITIES( mozilla-sync-caps.xml )
> Also: is the correct root element in the XML <capabilities> as in
> xmlformat test cases or <Cap> as in the group files ?
[...]
the XML schema for capabities can be found here:
https://svn.opensync.org/trunk/misc/schemas/capabilities.xsd
So its
<Caps><ObjType ...><Cap>...</Cap></ObjType></Caps>
Further questions?
Best Regards,
Daniel
--
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner
FOSS Developer Unternehmenssitz: Vohburg
B1 Systems GmbH Amtsgericht: Ingolstadt
Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537
EMail: go...@b1... http://www.b1-systems.de
Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D
|
|
From: Henrik /K. <kaa...@us...> - 2009-10-20 21:26:29
|
Thank you very, very much for the detailed answer!
This helps a lot.
I will try to make it work for mozilla-sync.
Just one follow-up question
The description.xml has much of the same info as the XXX_discover function.
Which is the preferred way of setting this? The xml file or the discover
function?
/Henrik
Daniel Gollub wrote:
> On Tuesday 20 October 2009 06:47:00 pm Henrik /KaarPoSoft wrote:
>
>> If I want to provide a static xml file with capabilities for my plugin
>> instead of using osync_capability_new in code, what do I call the file
>> and where do I put it?
>>
>
>
>
> $datadir/libopensync1/capabilities/
>
> e.g. /usr/local/share/libopensync1/capabilities/
>
>
>
> There is also a CMake variable you use to install to the correct path:
> ${OPENSYNC_CAPABILITIESDIR}
>
> e.g. ${OPENSYNC_CAPABILITIESDIR}/mozilla-sync.xml
>
>
> Beside this capabilities file, you need also to write a "description" file
> which points/refers the filename of your capabilities file (e.g. mozilla-
> sync.xml)
>
> Example of such a descriptino file is:
> trunk/misc/descriptions/syncml-nokia.xml
>
> -----8<-----
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <versions version="0.1">
> <version>
> <PlugIn>SyncML</PlugIn>
> <Priority>100</Priority>
> <Vendor>Nokia</Vendor>
> <ModelVersion>7650</ModelVersion>
> <FirmwareVersion></FirmwareVersion>
> <SoftwareVersion></SoftwareVersion>
> <HardwareVersion></HardwareVersion>
> <Identifier>syncml-nokia-7650.xml</Identifier>
> </version>
> </versions>
> ----->8-----
>
> In your case:
>
> -----8<-----
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <versions version="0.1">
> <version>
> <PlugIn>mozilla-sync</PlugIn>
> <Priority>100</Priority>
> <Vendor>Nokia</Vendor>
> <ModelVersion></ModelVersion>
> <FirmwareVersion></FirmwareVersion>
> <SoftwareVersion></SoftwareVersion>
> <HardwareVersion></HardwareVersion>
> <Identifier>mozilla-sync.xml</Identifier>
> </version>
> </versions>
> ------>8----
>
> Note that <Identifier> needs to be the filename (not the path!) of the
> capabilities xml file.
>
> place this as ... (again a cmake variable is available):
> ${OPENSYNC_DESCRIPTIONSDIR}/mozilla-sync.xml
>
>
> there are even cmake macros to install the description and capabilites file
>
> OPENSYNC_PLUGIN_DESCRIPTIONS( mozilla-sync-desc.xml )
> OPENSYNC_PLUGIN_CAPABILITIES( mozilla-sync-caps.xml )
>
>
>
>
>
>> Also: is the correct root element in the XML <capabilities> as in
>> xmlformat test cases or <Cap> as in the group files ?
>>
> [...]
>
> the XML schema for capabities can be found here:
> https://svn.opensync.org/trunk/misc/schemas/capabilities.xsd
>
> So its
>
> <Caps><ObjType ...><Cap>...</Cap></ObjType></Caps>
>
>
> Further questions?
>
>
> Best Regards,
> Daniel
>
>
|
|
From: Daniel G. <go...@b1...> - 2009-10-20 21:32:01
|
On Tuesday 20 October 2009 11:26:16 pm Henrik /KaarPoSoft wrote: > Just one follow-up question > The description.xml has much of the same info as the XXX_discover function. > Which is the preferred way of setting this? The xml file or the discover > function? > Ah - i forgot to mention this. you need both. In the discover() function you set information like the software version and stuff like that. OpenSync will later find the best fitting description file. The description winner's "<Reference>" will then choosen as reference for the capabilities file, which get used as the capabilities for this plugin/member/device ... In your case this looks pretty complex ... but this would allow you to support different version of mozilla-sync which might have different capabilities. e.g. due to bugs, or new features or so ... The many reason is actually for more general plugins to support different peers at the same time with compelelty different capabilities. Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
|
From: Henrik /K. <kaa...@us...> - 2009-10-20 21:42:25
|
Daniel Gollub wrote: > On Tuesday 20 October 2009 11:26:16 pm Henrik /KaarPoSoft wrote: > >> Just one follow-up question >> The description.xml has much of the same info as the XXX_discover function. >> Which is the preferred way of setting this? The xml file or the discover >> function? >> >> > > Ah - i forgot to mention this. > > you need both. > > In the discover() function you set information like the software version and > stuff like that. OpenSync will later find the best fitting description file. > The description winner's "<Reference>" will then choosen as reference for the > capabilities file, which get used as the capabilities for this > plugin/member/device ... > > In your case this looks pretty complex ... but this would allow you to support > different version of mozilla-sync which might have different capabilities. > e.g. due to bugs, or new features or so ... > > The many reason is actually for more general plugins to support different > peers at the same time with compelelty different capabilities. > > Best Regards, > Daniel > > Makes perfect sense! Thanks for the explanation! |
Thanks for helping keep SourceForge clean.
X