demerge_xmlformat does not demerge second level

[Henrik /KaarPoSoft-2]

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


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Wednesday 21 October 2009 06:57:55 pm Henrik /KaarPoSoft wrote:
[...]
> 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".
[...]
> (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?

Hmmm... no idea. I could imagine thats indeed a bug ...

>
> (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?
[...]

I could imagine this was very ugly porting when dropping the 2-level limit of
the xmlformat API to a n-level design.

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) 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/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel