opensync-users

[Opensync-users] Strange bug

[Jose de P. E. J. <jpe...@gm...>]

So, I can bring my data back from gpe plugin to files on my disk.
Using another pair, I can send the data on this file to evolution2.
Data from evolution2 is saved in vcards too, by the file plugin.
But when the gpe plugin gets a vcard from evolution I get this error:

Error writing entry query-2 to member 2: Couldn't commit todo: (null)
Mapping Write Error: Couldn't commit todo: (null)

I tried to edit the vcard from evolution and it has a lot more options
than the gpe one, I edited it manually to be equal to the gpe one and
no game. Even changed the name of the file, but it doesn't work.

Maybe a encoding problem? My machine is set to UTF8.

I couldn't find anything about debug options so... If anyone has any
idea, I'm open to them.

--=20
Jose de Paula Eufrasio Junior <jpe...@gm...>
aka coredump
http://coredump.osimortais.com.br

Re: [Opensync-users] Strange bug

[Jose de P. E. J. <jpe...@gm...>]

On 5/22/06, Martin Felis <ma...@si...> wrote:
> I fixed the bug which prevents the gpe plugin to report the actual
> error. If you use the version that is available through subversion,
> you will get a error message (no more Couldn't commit todo: (null) ).

Ahh. Now we're talking:

Error writing entry 20060522T034937Z-5556-1000-1-15@betty to member 2:
Couldn't commit todo:  invalid value in attribute LAST-MODIFIED
Mapping Write Error: Couldn't commit todo:  invalid value in attribute
LAST-MODIFIED

And the "LAST-MODIFIED" field on the vcard:

LAST-MODIFIED:20060522T034940

while the GPE ones are in that format:

LAST-MODIFIED:20060521T210325Z


Come'on, just because of the 'Z' on the end? :P Let's try
Yep. Added a Z on the end and worked like a charm.

--
Jose de Paula Eufrasio Junior <jpe...@gm...>
aka coredump
http://coredump.osimortais.com.br

Re: [Opensync-users] Strange bug

[Armin B. <arm...@de...>]

Jose de Paula Eufrasio Junior wrote:
> On 5/22/06, Martin Felis <ma...@si...> wrote:
>> I fixed the bug which prevents the gpe plugin to report the actual
>> error. If you use the version that is available through subversion,
>> you will get a error message (no more Couldn't commit todo: (null) ).
>=20
> Ahh. Now we're talking:
>=20
> Error writing entry 20060522T034937Z-5556-1000-1-15@betty to member 2:
> Couldn't commit todo:  invalid value in attribute LAST-MODIFIED
> Mapping Write Error: Couldn't commit todo:  invalid value in attribute
> LAST-MODIFIED
>=20
> And the "LAST-MODIFIED" field on the vcard:
>=20
> LAST-MODIFIED:20060522T034940
>=20
> while the GPE ones are in that format:
>=20
> LAST-MODIFIED:20060521T210325Z
>=20
>=20
> Come'on, just because of the 'Z' on the end? :P Let's try
> Yep. Added a Z on the end and worked like a charm.

hmm... i looked through the specs but couldnt find any information
whether timezone information should be included in LAST-MODIFIED (the
field doesnt even seem to be in the spec). so i _guess_ that this should
be fixed in gpe (although one could also argue that editing the vcard
has taken place at a location, so the timezone information should be
included)

Armin

>=20
> --=20
> Jose de Paula Eufrasio Junior <jpe...@gm...>
> aka coredump
> http://coredump.osimortais.com.br
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Opensync-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-users
>=20

[Opensync-users] Detection during conflict determination

[Graham C. <gr...@co...>]

Before I submit a bug ticket I thought I would check with the list to see if 
there was anything I missed.

It looks like format detection doesn't happen during conflict checking -- and 
it should.  

For example, if I sync between kdepim and file I can get a directory with file 
versions of my contacts, events and notes.  Great.  However, if I force a 
slow sync (without changing anything in the KDE side or in the files) every 
one of those files is marked as a conflict.

The problem is that the comparison check (to see if the entries conflict) is 
done with the XML datatype but that the file data cannot be converted to XML.  
Of course, when actually performing a change the file data is converted to 
XML perfectly well, but that requires using a detector.  And the detector is 
not used during the comparison check.

Is there any reason this shouldn't be regarded as a bug?  Is there some reason 
it is particularly hard to do?

Graham

Re: [Opensync-users] Detection during conflict determination

[Armin B. <arm...@de...>]

Graham Cobb wrote:
> Before I submit a bug ticket I thought I would check with the list to s=
ee if=20
> there was anything I missed.
>=20
> It looks like format detection doesn't happen during conflict checking =
-- and=20
> it should. =20
>=20
> For example, if I sync between kdepim and file I can get a directory wi=
th file=20
> versions of my contacts, events and notes.  Great.  However, if I force=
 a=20
> slow sync (without changing anything in the KDE side or in the files) e=
very=20
> one of those files is marked as a conflict.
>=20
> The problem is that the comparison check (to see if the entries conflic=
t) is=20
> done with the XML datatype but that the file data cannot be converted t=
o XML. =20
> Of course, when actually performing a change the file data is converted=
 to=20
> XML perfectly well, but that requires using a detector.  And the detect=
or is=20
> not used during the comparison check.
>=20
> Is there any reason this shouldn't be regarded as a bug?  Is there some=
 reason=20
> it is particularly hard to do?

Yes, this can be regarded as a bug and will be fixed in the next version
of opensync.

The problem with fixing this bug is:
Lets assume that we have telephone which can store notes and contacts.
We are synchronizing this telephone with a directory which contains a
single vcard. But opensync has a problem now: how should this file be
treated? Should it be synchronized as a contact or as a note? At the
moment it would be synchronized as a note (thats also the reason why the
comparison fails). But we cannot simply always run the detector on it,
because someone might want to really transfer it as a note.

But i already have a solution in mind. I just need to find some time to
implement it.

Armin

>=20
> Graham
>=20
>=20
> _______________________________________________
> Opensync-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-users
>=20

Re: [Opensync-users] Detection during conflict determination

[Graham C. <g+o...@co...>]

Armin,

Thanks for your reply.

On Monday 05 June 2006 01:16, Armin Bauer wrote:
> The problem with fixing this bug is:
> Lets assume that we have telephone which can store notes and contacts.
> We are synchronizing this telephone with a directory which contains a
> single vcard. But opensync has a problem now: how should this file be
> treated?  Should it be synchronized as a contact or as a note? 

Isn't this a different issue?   I understand that this process can cause 
problems if a file can be converted into two different types of entries but 
this conversion does happen when handling changes today.  I have created 
calendar and contacts entries as files and had them converted correctly, with 
no problems.

*My* problem is that this process does NOT occur when doing comparisons -- it 
only occurs when handling changes.  I think that whatever the process is for 
implementing changes, the SAME process needs to happen when doing 
comparisons.  Otherwise we see incorrect conflicts.

In the tests I have run (between file and kdepim formats), the problem is that 
the file data is not converted AT ALL during slow-sync comparison (it is not 
being converted to the wrong XML vformat datatype -- it is just not being 
converted at all).

Graham