opensync-devel — The place to coordinate the development of OpenSync

Re: [Opensync-devel] why long long?

[Henrik /K. <he...@ka...>]

Chris Frey wrote:
> On Sat, Oct 10, 2009 at 01:39:08PM +0200, Henrik /KaarPoSoft wrote:
>   
>> If we really want to stick to the frozen interface, we could use gint64
>> http://library.gnome.org/devel/glib/stable/glib-Basic-Types.html#gint64
>>     
>
> That would be worse in my opinion.
>
> long long is standard C99, it's just C++ that has trouble with it for now.
> The reason I brought it up was because it seemed silly to stretch
> C and C++ standards for values that rarely go above 2.
>
> - Chris
>   
I agree - it was just a "quick and dirty" if we really want to stick to 
frozen API.
In my opinion the best solution would to break API and change long long 
to long.

/Henrik

Re: [Opensync-devel] capabilities with attributes

[Henrik /K. <he...@ka...>]

Henrik /KaarPoSoft wrote:
> Daniel Gollub wrote:
>> On Tuesday 20 October 2009 07:02:17 pm Henrik /KaarPoSoft wrote:
>>  
>>> Some elements in an xml format can have attributes, such as:
>>> <Address Location="Home">
>>> Is there any way to define which such capabilities a plugin supports?
>>>
>>> One plugin may support only one address without specifying location,
>>> another plugin may support only Home,
>>> and a third may support Home and Work,
>>> etc. 
>> In theory: yes.
>>
>> Unfortuantely the xmlformat-merger and -demerger function is not yet 
>> handling attributes. It's just handles the fields.
>>
>> But you can already define capabilities that you only support a limit 
>> type of attributes - e.g. as value enumeration (valenum).
[SNIP]
>> Still, we would need to implement merger and demerger code to handle 
>> the XML attributes in the xmlformat plugin ...  
Here is a "real-life" example:


On the first slow sync between a syncml phone and mozilla-sync, the 
phone sends a VCARD with the line
TEL;PREF;WORK;VOICE:11111111

mozilla-sync does not have PREF nor VOICE, so it stores this phone 
number as WORK.

On the second slow sync, we then ge a conflict.

The above VCARD is translated to xml as:
<Telephone Preferred="true" Location="Work" Type="Voice">
 <Content>11111111</Content>
</Telephone>

Whereas the mozilla-sync entry is translated to
<Telephone Location="Work">
 <Content>11111111</Content>
</Telephone>

The two cards compare as SIMILAR (not SAME), because xmlformat_compare 
sees that the attribute count on <Telephone> is different.


So, if I understand correctly, what I need to do to get this to work is 
two things:
1) Patch merger and demerger code in xmlformat plugin
2) Add this to my capabilities:
<Cap>
 <Name>Telephone</Name>
 <Parameter>
  <Name>Location</Name>
  <ValEnum>Work</ValEnum>
 </Parameter>
</Cap>

It that correct?


/Henrik

[Opensync-devel] discover + sync = crash

[Chris F. <cd...@fo...>]

Hi,

If I apply the following patch to osynctool:

--- a/tools/osynctool.c
+++ b/tools/osynctool.c
@@ -1652,6 +1652,7 @@ int main (int argc, char *argv[])
                                goto error_free_group_env;
                        break;
                case OSYNCTOOL_SYNC:
+                       osynctool_configure_discover(group_env, plugin_env, groupname, membername, &error);
                        if (!osynctool_synchronize(group_env, groupname, wait, multi, slow_objects, &error)) {
                                g_list_free(slow_objects);
                                goto error_free_plugin_env;


Then when I run --sync (which now does the discover first), the sync
will give a segmentation fault.

I'm trying to figure out why this is the case, but if anyone has any
tips, I'm all ears.  I need this sort of behaviour so that it is safe
to do all the config, discover, and sync, from one instance of a program,
and not have to start fresh each time like osynctool.

Thanks,
- Chris

Re: [Opensync-devel] why long long?

[Chris F. <cd...@fo...>]

On Sat, Oct 10, 2009 at 01:39:08PM +0200, Henrik /KaarPoSoft wrote:
> If we really want to stick to the frozen interface, we could use gint64
> http://library.gnome.org/devel/glib/stable/glib-Basic-Types.html#gint64

That would be worse in my opinion.

long long is standard C99, it's just C++ that has trouble with it for now.
The reason I brought it up was because it seemed silly to stretch
C and C++ standards for values that rarely go above 2.

- Chris

Re: [Opensync-devel] why long long?

[Chris F. <cd...@fo...>]

On Sat, Oct 10, 2009 at 12:40:08PM +0200, Daniel Gollub wrote:
> On Friday 09 October 2009 09:35:59 pm Chris Frey wrote:
> > Why is the member ID so large?  Is there really a risk of
> >  9223372036854775807 different members?
> > 
> > The reason I ask is that 'long long' is not as portable as just long, and
> > there is no reason for such a large number, as far as I can see.
> > 
> 
> No idea, this was introduced long before i joined the OpenSync development.
> We should have a look into the subversion logs if Armin mentioned any reason 
> to use long long ...
> 
> How many public member/group interfaces are using long long?

Sorry for the delay on this.

This command shows about 22 functions:

	find . -type f -name "*.h" -print0 | \
		xargs -0 grep "long *long" | \
		grep EXPORT | \
		wc -l

There are also things like misc/schemas/capabilities.xsd that have
longlong and ulonglong for things such as AdvancedType.

- Chris

[Opensync-devel] demerge_xmlformat does not demerge second level

[Henrik /K. <he...@ka...>]

Dear all,

The function demerge_xmlformat in xmlformat_merge.c is supposed to 
remove the fields in the xml format which are not defined in the 
capabilities.

This seems to work fine on the top level, if we have a <Name> in the 
xmlformat, but not in the capabilities, osync_xmlfield_delete gets called.

However, on the second level, if we have a <LastName> inside a <Name> in 
the xmlformat, but not in the capabilities, the field is *not* deleted, 
instead the value of the field is set to blank.

This breaks the logic in xmlformat_compare, which will "Run out of list2 
elements".

I will try to provide a patch for demerge_xmlformat.

However, before I get too carried away, two questions:

(1) Does anyone know, WHY the second level of demerge_xmlformat was 
implemented like this? I.e. something that would break if we remove the 
field instead of blanking it?

(2) The top-level loop in demerge_xmlformat efficiently runs through the 
xml fileds with functions like osync_xmlfield_get_next. But the second 
level inefficiently uses indexes into the lists with functions like  
osync_xmlfield_get_nth_key_name. Is there any particular reason for this?

/Henrik

Re: [Opensync-devel] Getting things back on track

[Martin O. <doc...@gm...>]

Hey Daniel,

Good to see you,

On Mon, 2009-10-19 at 18:00 +0200, Daniel Gollub wrote:
> On Monday 19 October 2009 02:27:38 pm Martin Owens wrote:
> > Perhaps the problem is that the opensync project has attempted to solve
> > too many problems in the same framework?
> 
> Thats wrong - OpenSync actually only addresses: "Synchronisation Logic"
> 
> Data Access and Formating is done by plugins.

That's all very interesting in theory, but is not my point. Plugins are
by their nature 'a part of the framework'. While they are not part of
your codebase, they are a part of the execution flow and thus you have
device access, data access, formatting filtering and then
synchronization logic as part of the opensync framework.

Consider this instead:

> And they actually should use 
> libraries which have special formats or protocol implemented to convert a 
> format or access a device to gather/write data.

There is a shift from opensync plugins, all of which become deprecated.
Towards DeviceKit and Services file system plugins. This mates device
access and user online status with data access and provides a method for
all kinds of scripting and hacking on the resulting data that they
output (as files! how very unix).

I would expect each plugin to try and express it's data in a way that is
more direct, without too much filtering if it can be helped. But if it
turns out to be easier to output clean FreeDesktop.org or LSB vcards,
then so be it.

Otherwise some filtering programs, standard stuff. Data goes in, data
comes out cleaner.

Now here comes the fantastic part, you don't have to care where you get
your data from for syncing. It should be possible to just point opensync
at two directories full of vcards and have it do it's thing.

If that is all your program is doing, it makes the job fairly trivial to
program and test for. Version 1.0 blam, done, out the door and we can
all go home and have some crumpets.

I know it's not a popular idea to make certain things part of the
systematics of the operating system. But this is the best way to access
data and sync it, leaving the door open to the user so she can customise
how she wants to access the data if she wants.

And if your wondering about online services or local EDS/KDE-PIM access,
same rules apply. Just remember to use the services plugin system for
online.

Regards, Martin Owens

Re: [Opensync-devel] Fixing the OpenSync core development BUS factor

[Chris F. <cd...@fo...>]

On Tue, Oct 20, 2009 at 11:25:33PM +0200, Daniel Gollub wrote:
> I don't want to debug 0.39 from regular users, which using 0.39 because it got 
> shipped by their distro. I only want to debug 0.39 from a small amount of 
> people which are acting as tester and are not get angry if things doesn't work 
> as expected and are more willing to help and response in time ... ;)

This is a good point. :-)


> On Tuesday 20 October 2009 10:51:43 am Juha Tuomala wrote:
> > - drop 0.22
> 
> No - otherwise people start packaging 0.39 and put it in a distro ...

I think we should be encouraging distros to package both 0.22 and 0.4x.
The reason that Fedora got such flack for packaging 0.3x, in my opinion,
was because 0.22 disappeared.  The user needs to have a choice.

While 0.39 is not ready for production, there's no harm in packaging it
as long as it doesn't interfere with 0.22.

And fortunately, 0.39 won't interfere with 0.22 now.



> No - 0.39 is not working smooth enough ... there is this IPC issue we hit with 
> plugins like SyncML and others - which needs to be fixed.
> 
> The capsformat changes are not compleltey incoperatd.
> Currently you only really can sync "contact" ... not any other PIM format ...
> 
> Currently only the demerger is active, but not the merger!

More good points. :-)

- Chris

Re: [Opensync-devel] capabilities with attributes

[Henrik /K. <kaa...@us...>]

Daniel Gollub wrote:
> On Tuesday 20 October 2009 07:02:17 pm Henrik /KaarPoSoft wrote:
>   
>> Some elements in an xml format can have attributes, such as:
>> <Address Location="Home">
>> Is there any way to define which such capabilities a plugin supports?
>>
>> One plugin may support only one address without specifying location,
>> another plugin may support only Home,
>> and a third may support Home and Work,
>> etc.
>>
>>     
>
> In theory: yes.
>
> Unfortuantely the xmlformat-merger and -demerger function is not yet handling 
> attributes. It's just handles the fields.
>
> But you can already define capabilities that you only support a limit type of 
> attributes - e.g. as value enumeration (valenum).
>
>
> This is pretty new due to the new "capsformat" stuff.
>
> The capabilities defenition for your example would look then something like 
> that:
>
>
> Caps example which supports only Home and Work:
> -----8<------
> <?xml version="1.0"?>
> <Caps Version="1.0" CapsFormat="xmlformat">
>   <ObjType Name="contact">
>     <Cap>
>       <Name>Address</Name>
>       <Parameter>
>          <Name>Location</Name>
>          <ValEnum>Home</ValEnum>
>          <ValEnum>Work</ValEnum>
>       </Parameter>
>     </Cap>
> [...]
>    </ObjType>
> </Cap>
> ------>8-----
>
>
>
> supports only Home:
> -----8<------
> <?xml version="1.0"?>
> <Caps Version="1.0" CapsFormat="xmlformat">
>   <ObjType Name="contact">
>     <Cap>
>       <Name>Address</Name>
>       <Parameter>
>          <Name>Location</Name>
>          <ValEnum>Home</ValEnum>
>       </Parameter>
>     </Cap>
> [...]
>    </ObjType>
> </Cap>
> ------>8-----
>
>
> supports no specific location
> -----8<------
> <?xml version="1.0"?>
> <Caps Version="1.0" CapsFormat="xmlformat">
>   <ObjType Name="contact">
>     <Cap>
>       <Name>Address</Name>
>     </Cap>
> [...]
>    </ObjType>
> </Cap>
> ------>8-----
>
> Supports all values for Location:
> -----8<------
> <?xml version="1.0"?>
> <Caps Version="1.0" CapsFormat="xmlformat">
>   <ObjType Name="contact">
>     <Cap>
>       <Name>Address</Name>
>       <Parameter>
>          <Name>Location</Name>
>       </Parameter>
>     </Cap>
> [...]
>    </ObjType>
> </Cap>
> ------>8-----
>
>
> Do you think this kind of capabilities definition would represent all the 
> combinations?
>
> Still, we would need to implement merger and demerger code to handle the XML 
> attributes in the xmlformat plugin ...
>
>
> Best Regards,
> Daniel
>
>   
At the face of it, this seems to make sense.
However, I need to work on "my" mozilla-sync capabilities a bit more, 
before I can answer whether
"this kind of capabilities definition would represent all the

combinations?"

Re: [Opensync-devel] Fixing the OpenSync core development BUS factor

[Daniel G. <go...@b1...>]

On Tuesday 20 October 2009 12:31:06 am Paul Eggleton wrote:
[...]
> I'm not quite sure how to decide which areas I would work on in the core;
>  as you say there is great temptation to take on the areas that are most
>  important to me as a plugin developer. I agree though that that will
>  ultimately not solve anything.
> 
> I have some hesitation in doing this, but perhaps if I can take these two
> 
> items for now:
> >  - Synchronization Engine (workflow of the Synchronization: connect,
> >    get_changes, ...)
> >    * documentation
> >    * cleanup
> >    * maintenance
> >    * bugfixing
> >    * profiling
> >  - Format Conversion (abstract logic to convert formats, e.g. conversion
> >    pathes, ...)
> >    * review of the conversion path building process
> >    * profiling
> >    * documentation
> 
> I don't know if we have much time for profiling at the moment :)

Yeah profiling is not so critical today ... we might do this with version 0.99 
or so ;)

> Bugfixes
>  and understanding & documenting the process are a lot more important right
>  now.

ACK

>  I am still also ready to do fixes and completion of the API
>  documentation in any of the areas required, but what I am usually lacking
>  there is understanding about how some of the functions should work.
[...]

The easiest thing for me would be that you start with how the application API 
get used - e.g. osynctool - or convtool (from vformat plugin - for format 
conversion).


For Engine the public API function are acutally just those:

osync_engine_new()
osync_engine_initiazile()
osync_engine_synchronize_and_block() <- this is doin' the entire sync
osync_engine_finalize()
osync_engine_unref()

So i would suggest you start looking into osync_engine_initiazile() and 
osync_engine_synchronize_and_block() ... there are also some junks in the 
OpenSync how the inner engine works.

As soon you have question drop a mail on opensync-devel@

Maybe for the beginning you could try to find out the order of the plugin 
calls in the engine - e.g. connect(), disconnect(), get_changes() ... and so 
on ... once you find your way through that it's quite easy to find throught 
the stack from engine call to the plugin call...

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

Re: [Opensync-devel] xml file with capabilities

[Henrik /K. <kaa...@us...>]

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!

Re: [Opensync-devel] xml file with capabilities

[Daniel G. <go...@b1...>]

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

Re: [Opensync-devel] xml file with capabilities

[Henrik /K. <kaa...@us...>]

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
>
>   

Re: [Opensync-devel] Fixing the OpenSync core development BUS factor

[Daniel G. <go...@b1...>]

On Tuesday 20 October 2009 10:51:43 am Juha Tuomala wrote:
[...]
> That's what i suggested a long time ago. We need to officially
> announce 0.22 dead, kill it. Fedora upgraded their versions to 0.3x and
> then reverted back to 0.22 even i tried to stop that idea there too. :)
> 
> If you want to keep everyones eyeballs out of focus (current code), best
> way to do is to distract them to look something else. _Opensync is a name
> that stands for the concept of pda syncing_. Everyone knows it already.
> 
> People stare at the 0.22 and see that's it is not good for anything else
> than filling a package in distro.
> 
> That damages both our needs (more eyeballs) and the name. There is no need
> to keep an active placeholder in distros, since everyone knows the name
>  already.
> 
> So, i suggest (with quite minimal effort):
> 
> - drop 0.22

No - otherwise people start packaging 0.39 and put it in a distro ...

> - leave space empty or...
> 
>   Perhaps we should just lift the ban to upgrade distro releases for 0.39?

No - 0.39 is not working smooth enough ... there is this IPC issue we hit with 
plugins like SyncML and others - which needs to be fixed.

The capsformat changes are not compleltey incoperatd.
Currently you only really can sync "contact" ... not any other PIM format ...

Currently only the demerger is active, but not the merger!


I don't want to debug 0.39 from regular users, which using 0.39 because it got 
shipped by their distro. I only want to debug 0.39 from a small amount of 
people which are acting as tester and are not get angry if things doesn't work 
as expected and are more willing to help and response in time ... ;)


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

Re: [Opensync-devel] xml file with capabilities

[Daniel G. <go...@b1...>]

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

Re: [Opensync-devel] Review of patch for ticket 1171: vformat to compile on Windows

[Henrik /K. <kaa...@us...>]

You answerd:
why not using g_mkstemp_full() directly from glib?

To which I say:
Because it creates a temporary FILE and what we need is a DIRECTORY.


Daniel Gollub wrote:
> On Tuesday 20 October 2009 09:55:57 pm Henrik /KaarPoSoft wrote:
>   
>> Please review the patch attached to
>> http://opensync.org/ticket/1171
>>
>>     
>
> replied the ticket in ticketsytem ...
>
>   

Re: [Opensync-devel] capabilities with attributes

[Daniel G. <go...@b1...>]

On Tuesday 20 October 2009 07:02:17 pm Henrik /KaarPoSoft wrote:
> Some elements in an xml format can have attributes, such as:
> <Address Location="Home">
> Is there any way to define which such capabilities a plugin supports?
> 
> One plugin may support only one address without specifying location,
> another plugin may support only Home,
> and a third may support Home and Work,
> etc.
> 

In theory: yes.

Unfortuantely the xmlformat-merger and -demerger function is not yet handling 
attributes. It's just handles the fields.

But you can already define capabilities that you only support a limit type of 
attributes - e.g. as value enumeration (valenum).


This is pretty new due to the new "capsformat" stuff.

The capabilities defenition for your example would look then something like 
that:


Caps example which supports only Home and Work:
-----8<------
<?xml version="1.0"?>
<Caps Version="1.0" CapsFormat="xmlformat">
  <ObjType Name="contact">
    <Cap>
      <Name>Address</Name>
      <Parameter>
         <Name>Location</Name>
         <ValEnum>Home</ValEnum>
         <ValEnum>Work</ValEnum>
      </Parameter>
    </Cap>
[...]
   </ObjType>
</Cap>
------>8-----



supports only Home:
-----8<------
<?xml version="1.0"?>
<Caps Version="1.0" CapsFormat="xmlformat">
  <ObjType Name="contact">
    <Cap>
      <Name>Address</Name>
      <Parameter>
         <Name>Location</Name>
         <ValEnum>Home</ValEnum>
      </Parameter>
    </Cap>
[...]
   </ObjType>
</Cap>
------>8-----


supports no specific location
-----8<------
<?xml version="1.0"?>
<Caps Version="1.0" CapsFormat="xmlformat">
  <ObjType Name="contact">
    <Cap>
      <Name>Address</Name>
    </Cap>
[...]
   </ObjType>
</Cap>
------>8-----

Supports all values for Location:
-----8<------
<?xml version="1.0"?>
<Caps Version="1.0" CapsFormat="xmlformat">
  <ObjType Name="contact">
    <Cap>
      <Name>Address</Name>
      <Parameter>
         <Name>Location</Name>
      </Parameter>
    </Cap>
[...]
   </ObjType>
</Cap>
------>8-----


Do you think this kind of capabilities definition would represent all the 
combinations?

Still, we would need to implement merger and demerger code to handle the XML 
attributes in the xmlformat plugin ...


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

Re: [Opensync-devel] Integration with iTunes

[Henrik /K. <kaa...@us...>]

Hi Todd,

I have updated the Windows build instructions:
http://kaarposoft.dk/bluezync/building.html#building_windows

It still does not work, but we are getting closer!
Maybe you could try to see if the instructions work for you,
and post the results here on the opensync-devel list.

/Henrik


Henrik /KaarPoSoft wrote:
> Hi Todd,
>
> I have tried to build OpenSync and the mozilla-sync plugin on Windows.
> You can have a look here: 
> http://bluezync.kaarposoft.dk/building.html#building_windows
> However, since Mozilla now recommends using Visual Studio Express from 
> Microsoft (free, but not open source), I will try this instead.
>
> There are also some windows building instructions here: 
> http://opensync.org/wiki/devel/compilingForWindows
> but note that they use cygwin, so my guess is that although OpenSync 
> might build, you will have problems with Mozilla.
>
> Be warned, that buidling OpenSync and mozilla-sync on a non-linux 
> platform is NOT easy !
>
> Apart from that, it would be great to have a iTunes plugin - for any 
> platform...
>
> /Henrik
>
>
> Todd Nine wrote:
>   
>> Hi all,
>>   I'm working on trying to integrate Mozilla Lightning and Sunbird 
>> with iTunes.  It seems like a lot of sync work has already been done 
>> with the mozilla plugin that will allow me to interact with the 
>> calendar.  From my basic understanding of the API, I can write a sync 
>> plugin for iTunes that will allow iTunes integration with any plugin 
>> that opensync provides.  Given that my initial target release will be 
>> Windows, are there any good examples of creating a simple binary that 
>> can be used on the Windows platform?  I want to make installation of 
>> this iTunes plugin easy, so I just want to include the neccessary DLL 
>> files within my plugin.
>>
>> Thanks,
>> Todd
>>     
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
>   

Re: [Opensync-devel] Review of patch for ticket 1170: Error in _osync_obj_engine_mapping_find

[Daniel G. <go...@b1...>]

On Tuesday 20 October 2009 09:57:59 pm Henrik /KaarPoSoft wrote:
> Please review the last patch included in
> http://opensync.org/ticket/1170
> 
> Should I commit?
> 


Uuuuh, this was a nasty one ... looks good to me. Please commit!

Thanks a lot!

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

Re: [Opensync-devel] Review of patch for ticket 1173 conv_xmlformat_to_vcard invents empty property components

[Daniel G. <go...@b1...>]

On Tuesday 20 October 2009 09:52:33 pm Henrik /KaarPoSoft wrote:
> Please review the patch attached to
> http://opensync.org/ticket/1173
> 
> Should I commit?
> And should I do the same to other similar properties?
> 

I hope Christopher can comment on that.

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

Re: [Opensync-devel] Review of patch for ticket 1172: osync_bool osync_group_env_setup_config_dir fails

[Daniel G. <go...@b1...>]

On Tuesday 20 October 2009 09:54:10 pm Henrik /KaarPoSoft wrote:
> Please review the patch attached to
> http://opensync.org/ticket/1172
> 
> Should I commit?
> 

Looks good to me, please commit and close the ticket.

Thanks!

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

Re: [Opensync-devel] Review of patch for ticket 1171: vformat to compile on Windows

[Daniel G. <go...@b1...>]

On Tuesday 20 October 2009 09:55:57 pm Henrik /KaarPoSoft wrote:
> Please review the patch attached to
> http://opensync.org/ticket/1171
> 

replied the ticket in ticketsytem ...

-- 
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

Re: [Opensync-devel] Fixing the OpenSync core development BUS factor

[Henrik /K. <kaa...@us...>]

Daniel Gollub wrote:
> On Tuesday 20 October 2009 06:35:51 pm Henrik /KaarPoSoft wrote:
>   
>> Until now, when I have found bugs, I have filed tickets - sometimes with 
>> patches.
>> As a result, others have either rejected the patches, committed them, or 
>> committed them in a modified form.
>> Would it be beneficial if I just check in my patches directly?
>>     
> [...]
>
> I would say this depends how complex your modification is. If your sure this 
> is a trivial modification go ahead and commit it (and make sure it passes the 
> entire testsuite and doesn't cause any regression).
>
> If it's a more complex chance please always send the patch to opensync-devel 
> and ask for review. If there is no response within 2 days, feel free to commit 
> it directly ...
>
>
> Does this sounds sane to you?
>
> Best Regards,
> Daniel
>
>   
Let's try it out !

/Henrik

[Opensync-devel] Review of patch for ticket 1170: Error in _osync_obj_engine_mapping_find

[Henrik /K. <kaa...@us...>]

Dear fellow developers,

Please review the last patch included in
http://opensync.org/ticket/1170

Should I commit?

Thanks in advance
/Henrik

[Opensync-devel] Review of patch for ticket 1171: vformat to compile on Windows

[Henrik /K. <kaa...@us...>]

Dear fellow developers,

Please review the patch attached to
http://opensync.org/ticket/1171

Should I commit?

Thanks in advance
/Henrik