OK, I got it. The bug is in xml_vcard.c. It used "Name" instead of
"NodeName" for the XML node. Here is the diff from SVN:

Index: formats/vformats-xml/xml-vcard.c
===================================================================
--- formats/vformats-xml/xml-vcard.c    (revision 472)
+++ formats/vformats-xml/xml-vcard.c    (working copy)
@@ -476,7 +476,7 @@
 static VFormatAttribute *xml_handle_unknown_attribute(VFormat *vcard,
xmlNode *root, const char *encoding)
 {
        osync_trace(TRACE_INTERNAL, "Handling unknown xml attribute %s",
root->name);
-       char *name = osxml_find_node(root, "Name");
+       char *name = osxml_find_node(root, "NodeName");
        VFormatAttribute *attr = vformat_attribute_new(NULL, name);
        add_value(attr, root, "Content", encoding);
        vformat_add_attribute(vcard, attr);

Enjoy.
  Paul Rensing

On Sat, 2005-04-09 at 17:33 +0200, Armin Bauer wrote:
> 
> Paul Rensing wrote:
> > I am testing out Opensync and came across a problem syncing Evolution2
> > to the File plugin. The problem is that Evo2 has entries in the VCARD
> > (contact):
> >   X-EVOLUTION-LAST-USE
> >   X-EVOLUTION-USE-SCORE
> > The file-sync plugin outputs the values but not the labels into the
> > files on disk. For example:
> >
> > :2004-11-05
> > :1.973193
> >
> > Presumably, this could be fixed by adding those to the evolution XML
> > extensions, however, I wonder if that is the right way to go.
> > Presumably, many plugins will have extension fields which one would not
> > want to track. The XML format could have a generic parameter format,
> > something like:
> >
> >      <param name="X-EVOLUTION-LAST-USE">2004-11-05</param>
> >
> 
> it would be the correct thing to do. the xml format is supposed to
> support _everything_ that the other format can support (besides local
> stuff like the uid). This should be done since at some point opensync is
> supposed to support "merging" of objects and if we dont convert
> information to the xml format we would loose it.
> 
> Opensync already has support for mapping fields it does not know yet.
> Normally it should add a <UnknownNode> node to the xml doc but i guess
> there must be a bug since it is not working for you :)
> 
> could you please turn on tracing with: export
> OSYNC_TRACE=/path/to/some/log/directory
> and run the command again that yielded this wrong conversion? you can
> either send the resulting Thread*.log files directly or just the
> conversion part (the interesting part would be the input vcard and the
> output xml tree)
> 
> what version of evolution and evolution-data-server are you running?
> 
> > Paul Rensing
> >
-- 
Paul Rensing <[EMAIL PROTECTED]>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Multisync-users mailing list
Multisync-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/multisync-users

Reply via email to