Menu
▾
▴
opensync-devel — The place to coordinate the development of OpenSync
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(9) |
Apr
(84) |
May
(18) |
Jun
(12) |
Jul
(6) |
Aug
(7) |
Sep
(10) |
Oct
(31) |
Nov
(59) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(53) |
Feb
(15) |
Mar
(43) |
Apr
(40) |
May
(63) |
Jun
(142) |
Jul
(54) |
Aug
(31) |
Sep
(30) |
Oct
(39) |
Nov
(36) |
Dec
(64) |
| 2007 |
Jan
(128) |
Feb
(261) |
Mar
(156) |
Apr
(127) |
May
(76) |
Jun
(131) |
Jul
(83) |
Aug
(124) |
Sep
(83) |
Oct
(88) |
Nov
(180) |
Dec
(90) |
| 2008 |
Jan
(86) |
Feb
(93) |
Mar
(117) |
Apr
(104) |
May
(65) |
Jun
(35) |
Jul
(38) |
Aug
(111) |
Sep
(58) |
Oct
(33) |
Nov
(102) |
Dec
(194) |
| 2009 |
Jan
(193) |
Feb
(74) |
Mar
(111) |
Apr
(77) |
May
(31) |
Jun
(20) |
Jul
(1) |
Aug
(3) |
Sep
(57) |
Oct
(125) |
Nov
(50) |
Dec
(3) |
| 2010 |
Jan
(26) |
Feb
(5) |
Mar
(13) |
Apr
(3) |
May
(3) |
Jun
(12) |
Jul
(27) |
Aug
(47) |
Sep
(105) |
Oct
(53) |
Nov
(34) |
Dec
(21) |
| 2011 |
Jan
(115) |
Feb
(17) |
Mar
|
Apr
(6) |
May
(16) |
Jun
(15) |
Jul
(85) |
Aug
(21) |
Sep
(13) |
Oct
(12) |
Nov
(28) |
Dec
(23) |
| 2012 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(5) |
Jul
(5) |
Aug
(31) |
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(33) |
Sep
(9) |
Oct
(10) |
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
| 2016 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: deloptes <del...@ya...> - 2011-01-23 22:29:12
|
Chris Frey wrote: > > When I looked at the code briefly the other day, it seemed to take this > configuration and load it into a list, and then it would check the > list periodically during the sync. I think there was a function, > "hasCategory()" or something in the process. > > Grep through the code, and I'm sure you'll find it, starting with > "FilterCategory" and proceeding backward. I'm assuming "hasCategory()" > is where the answer will be (I'm not sure of the spelling/capitalizaion > of the function anymore). > > - Chris > I could compile and install kdepim-sync in trinity. After configuring and compiling everything, I could track this down and found out it checks == 0 if the field is empty, so I used no value. The capabilities issue, I fixed by removing the kdepim-sync-capabilities.xml file and related kdepim-sync-description.xml. I'm wondering why it is getting assertion error when the files are present. Now I could even sync kdepim with the nokia phone. But it does not merge any changes. It just suggests to add/delete, so I removed everything from the kde address book and synced. There were too many duplicates, how could this happen, were those on the phone? The phone reports 887 changes I deleted most of them and synced but it suggested to add/delete 469 entries, so I answered 'N'. A bit strange all of this. Looking into the new created file I could see most of the entries were with ID 1-900 but there were also such with KDE ids. Let me know if you have some confident way to test/sync regards |
|
From: Emanoil K. <del...@ya...> - 2011-01-21 10:08:20
|
Hi, thanks for the discussion and paying attention to this subject.
--- On Thu, 1/20/11, Chris Frey <cd...@fo...> wrote:
> > > Experience teaches us that implementation of the
> V-formats in the real world
> > > is very poor! It would be worth both the
> vformat and xmlformat code in
> > > OpenSync to be more tolerant. OpenSync is
> in the business of syncing user's
> > > devices, not enforcing minor standards
> violations.
> >
> > Yes, you are absolutely right. OpenSync should
> be way more
> > tolerant towards format errors. A format error
> is not the same
> > as an exit error in terms of libopensync, which
> automatically
> > leads to slow-sync of all of the entries available.
>
> I don't know which software stack is creating this vCard
> data.
>
> Emanoil: can you let us know if you are getting this data
> from Akonadi
> or if you are creating it
> yourself? If the plugin is creating
> the vCard data, the plugin should be
> fixed, not the parser.
The history as follows. After I bought the phone I used windows to sync my contacts from the old phones (nokia and sony-err). I've managed then to sync my contacts with kde3 (somehow, with having a lot of duplicates) with opensync 0.22. After this I've been using Nokia in windows (vmware) and later the SyncEvolution app. So I guess somehow this contact was transfered to the phone. Now the strange thing is that this GEO field is not visible on the phone and I can not edit it.
>
> But, if people have time on their hands, and want to hack
> on the code,
> go to the vformat plugin, in src/xmlformat-vcard.c, line
> 444, and
> change the handle_location_attribute() function. Test
> code would also
> be nice. :-)
>
I'll have a look at it.
regards
|
|
From: Chris F. <cd...@fo...> - 2011-01-20 19:42:52
|
On Thu, Jan 20, 2011 at 08:31:07PM +0100, Juergen Leising wrote: > On Thu, Jan 20, 2011 at 02:49:55PM +0000, Graham Cobb wrote: > > On Wednesday 19 January 2011 02:12:31 Chris Frey wrote: > > > On Tue, Jan 18, 2011 at 02:49:20PM -0800, Emanoil Kotsev wrote: > (...) > > > Experience teaches us that implementation of the V-formats in the real world > > is very poor! It would be worth both the vformat and xmlformat code in > > OpenSync to be more tolerant. OpenSync is in the business of syncing user's > > devices, not enforcing minor standards violations. > > Yes, you are absolutely right. OpenSync should be way more > tolerant towards format errors. A format error is not the same > as an exit error in terms of libopensync, which automatically > leads to slow-sync of all of the entries available. I don't know which software stack is creating this vCard data. Emanoil: can you let us know if you are getting this data from Akonadi or if you are creating it yourself? If the plugin is creating the vCard data, the plugin should be fixed, not the parser. But, if people have time on their hands, and want to hack on the code, go to the vformat plugin, in src/xmlformat-vcard.c, line 444, and change the handle_location_attribute() function. Test code would also be nice. :-) - Chris |
|
From: Juergen L. <jue...@gm...> - 2011-01-20 19:31:23
|
On Thu, Jan 20, 2011 at 02:49:55PM +0000, Graham Cobb wrote: > On Wednesday 19 January 2011 02:12:31 Chris Frey wrote: > > On Tue, Jan 18, 2011 at 02:49:20PM -0800, Emanoil Kotsev wrote: (...) > Experience teaches us that implementation of the V-formats in the real world > is very poor! It would be worth both the vformat and xmlformat code in > OpenSync to be more tolerant. OpenSync is in the business of syncing user's > devices, not enforcing minor standards violations. Yes, you are absolutely right. OpenSync should be way more tolerant towards format errors. A format error is not the same as an exit error in terms of libopensync, which automatically leads to slow-sync of all of the entries available. (...) > There may also be a case that the xmlformat code should just be dropping badly > formatted fields although, as a purely internal format, I can see the > justification for aborting, but only if the code which creates the XML is > capable enough to always generate either no field or a correctly formatted > field. (...) Exactly. A WARNING would do it, as well. Bye, bye Juergen. |
|
From: Michael B. <mic...@cm...> - 2011-01-20 16:37:17
|
Hi, I just released the first beta of libwbxml 0.11.x. There will be no normal release info because it is a beta. So just some short notes: 1. The API was reduced. There will be now 4 installed header files instead of 18. There are now exactly three functions. 2. The character conversion code was updated. This interface bug was the main reason to break the binary compatibility. 3. The code pages for the Microsoft Active Sync conversion were updated. Best regards Michael -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 70143 ZE Computer- und Medienservice Fax: +49 (0)30-2093 70135 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB |
|
From: Graham C. <g+o...@co...> - 2011-01-20 14:50:09
|
On Wednesday 19 January 2011 02:12:31 Chris Frey wrote: > On Tue, Jan 18, 2011 at 02:49:20PM -0800, Emanoil Kotsev wrote: > > GEO:48.150002\;17.116667 > > There appears to be a problem with this line. If you remove the > escape backslash, then it should work. > > Otherwise, the full string is taken as the Latitude (48.150002;17.116667) > and there is no Longitude, and the XMLFormat validation rightly > complains. Experience teaches us that implementation of the V-formats in the real world is very poor! It would be worth both the vformat and xmlformat code in OpenSync to be more tolerant. OpenSync is in the business of syncing user's devices, not enforcing minor standards violations. As this particular bad encoding has now been seen in the real world we can assume it will be seen again. It seems like the vformat code could, and should, handle it, as a variant and parse the GEO: with the \; as well as the correct version without the \. However, in any case, it should also make sure it **always** generates valid XML (or none at all). So, GEO:xxx should generate either no <Location> or a valid one. There may also be a case that the xmlformat code should just be dropping badly formatted fields although, as a purely internal format, I can see the justification for aborting, but only if the code which creates the XML is capable enough to always generate either no field or a correctly formatted field. Graham |
|
From: deloptes <del...@ya...> - 2011-01-19 23:01:33
|
deloptes wrote: > I think I had the check for RemoteId in the code (and removed it for some > reason ... ). I need to code some better solution. I had a look but the problem seem to be that in kde the UID is defined as qint64, so I need to find a way to solve it :-( ... to convert it regards |
|
From: deloptes <del...@ya...> - 2011-01-19 21:49:16
|
Chris Frey wrote:
> On Sun, Jan 16, 2011 at 06:15:57PM +0100, deloptes wrote:
>> The question was how to implement the check in akonadi because akonadi
>> has a revision number which is incremented internally every time you edit
>> the record. It has ID and RemoteID, so I was not sure what I should
>> check. I'm
>> still not sure the way I've implemented it is the best one, but for the
>> time and stage of development it is also satisfactory. The current
>> solution uses RemoteID for change-id and the Revision for the hash (hash
>> = RemoteID+"-"+Revision. I am not sure if I need to keep a tack of the
>> akonadiId.
What I mean is exactly the example below. Notice the UID entry. I think I
need to do a mapping between the IDs of the devices or setting the RemoteID
to the UID when the former is missing. It is getting a bit complicated.
However the only difference is the UID, which is used in the hash.
I think I had the check for RemoteId in the code (and removed it for some
reason ... ). I need to code some better solution.
This behavior also depends in the way one syncs first. Is there data on the
phone or not and vice versa.
Member: 2 (akonadi-sync)
UID: dmY7a5NAzE
<?xml version="1.0"?>
<contact>
<EMail>
<Content>xxxxxxxxxxxxxx</Content>
</EMail>
<Name>
<LastName>xxxxxxxxxxxxxx</LastName>
<FirstName>xxxxxxxxxxxxxx</FirstName>
<Additional></Additional>
<Prefix></Prefix>
<Suffix></Suffix>
</Name>
<Revision>
<Content>20100723T191711Z</Content>
</Revision>
<Telephone Type="Cellular">
<Content>xxxxxxxxxxxxxx</Content>
</Telephone>
</contact>
Entry 2:
Member: 1 (syncml-obex-client)
UID: 48
<?xml version="1.0"?>
<contact>
<EMail Type="Internet">
<Content>xxxxxxxxxxxxxx</Content>
</EMail>
<Name>
<LastName>xxxxxxxxxxxxxx</LastName>
<FirstName>xxxxxxxxxxxxxx</FirstName>
<Additional></Additional>
<Prefix></Prefix>
<Suffix></Suffix>
</Name>
<Revision>
<Content>20100723T191711Z</Content>
</Revision>
<Telephone Type="Cellular">
<Content>xxxxxxxxxxxxxx</Content>
</Telephone>
</contact>
|
|
From: Emanoil K. <del...@ya...> - 2011-01-19 21:33:22
|
hi, thanks, this was the blocking issue
unfortunately I couldn't edit this field on the phone. it was not visible there, so I've just deleted the entry and I was able to sync my contatcs to akonadi.
May be some of the other "cool" sync applications did this to the GEO field. no idea
my next goal would be to handle this with kdepim.
I can not read the calendar from the phone :-( but this is another topic. I'll post my findings in the akonadi thread.
regards
|
|
From: Juergen L. <jue...@gm...> - 2011-01-19 18:44:53
|
Hello, I have written a CALDAV plugin, using libneon. The plugin supports the object types "event", "todo" and "note", but it does NOT support VFREEBUSY entries, yet. The plugin is in a simple shape and certainly requires quite a lot of further development, especially when it comes to - the authentication/authorization, - the SSL verification, - the communication with the CALDAV server in general and - to some other features. The plugin has been tested against the CALDAV server "davical": http://sourceforge.net/projects/davical/ http://debian.mcmillan.net.nz/ I would like to check it in. My login name to the svn tree is "scriptor". Bye, bye Juergen |
|
From: ashish c. <ash...@gm...> - 2011-01-19 15:01:35
|
Hi, thanks for your time,but can you please tell me that syncml-ds-tool which is there in libsyncml->tools is using only syncml api's or some other api's also? form where i can start writing application using syncml for syncronizing my phonebook with my system. Detailed steps would be a great help.thank u |
|
From: Emanoil K. <del...@ya...> - 2011-01-19 10:51:56
|
--- On Wed, 1/19/11, Chris Frey <cd...@fo...> wrote: > From: Chris Frey <cd...@fo...> > Subject: Re: [Opensync-devel] OpenSync priorities > To: ope...@li... > Date: Wednesday, January 19, 2011, 3:12 AM > On Tue, Jan 18, 2011 at 02:49:20PM > -0800, Emanoil Kotsev wrote: > > VERSION:2.1 > > REV:20100725T123728Z > > N:XXXX;Markus;;; > > FN:Markus XXXX > > ADR;HOME;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:= > > > 7/2/8;;XXXXXXXXXXXXX=0D=0ANr.=207=0D=0AStiege=202=0D=0AT=C3=BCr=208;Wien;;= > > 1070;=C3=96sterreich > > ORG:;4 Semester > > BDAY:19840423 > > > EMAIL;INTERNET;ENCODING=QUOTED-PRINTABLE:ich=40markus-raab.org > > GEO:48.150002\;17.116667 > > There appears to be a problem with this line. If you > remove the > escape backslash, then it should work. > > Otherwise, the full string is taken as the Latitude > (48.150002;17.116667) > and there is no Longitude, and the XMLFormat validation > rightly > complains. > Thanks. I'll try to do this next. regards |
|
From: Chris F. <cd...@fo...> - 2011-01-19 02:12:38
|
On Tue, Jan 18, 2011 at 02:49:20PM -0800, Emanoil Kotsev wrote: > VERSION:2.1 > REV:20100725T123728Z > N:XXXX;Markus;;; > FN:Markus XXXX > ADR;HOME;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:= > 7/2/8;;XXXXXXXXXXXXX=0D=0ANr.=207=0D=0AStiege=202=0D=0AT=C3=BCr=208;Wien;;= > 1070;=C3=96sterreich > ORG:;4 Semester > BDAY:19840423 > EMAIL;INTERNET;ENCODING=QUOTED-PRINTABLE:ich=40markus-raab.org > GEO:48.150002\;17.116667 There appears to be a problem with this line. If you remove the escape backslash, then it should work. Otherwise, the full string is taken as the Latitude (48.150002;17.116667) and there is no Longitude, and the XMLFormat validation rightly complains. - Chris |
|
From: Emanoil K. <del...@ya...> - 2011-01-18 22:49:28
|
it seems I can not reproduce this any more --- On Fri, 1/14/11, Chris Frey <cd...@fo...> wrote: > > > > http://www.opensync.org/ticket/1442 > > http://www.opensync.org/ticket/1444 - a > problem in the parser (converter) breaks sync of contact > data > > > Can you grab the latest vformat plugin from SVN and give it > a try? > > If it works, can you close the above tickets for me? :-) > however I have this error, which sounds like http://www.opensync.org/ticket/1182 and http://www.opensync.org/ticket/1173 and http://www.opensync.org/ticket/1147 element Location: Schemas validity error : Element 'Location': Missing child element(s). Expected is ( Longitude ). ERROR: XMLFormat validation failed. EXIT_ERROR: osync_converter_invoke: XMLFormat validation failed. EXIT_ERROR: osync_format_env_convert: XMLFormat validation failed. Main sink of member 1 of type syncml-obex-client had an error: XMLFormat validation failed. EXIT_ERROR: _osync_engine_receive_change: XMLFormat validation failed. in the thread log [1295389667.347122] >>>>>>> _osync_client_proxy_message_handler(0x7f7e9c13c940, 0x237aea0) [1295389667.347135] proxy received command 10 [1295389667.347150] Data is: 0x7f7e940ec6d0, 2327 [1295389667.347172] >>>>>>> _osync_engine_receive_change(0x237aea0, 0x21b7020, 0x7f7e940e9270) [1295389667.347185] Received change 540, changetype 1, format vcard21, objtype contact from member 1 [1295389667.347199] >>>>>>> osync_format_env_detect_objformat_full(0x21b9980, 0x7f7e940eb180, 0x7f7ea5f3ec28, 0x7f7ea5f3ec30) [1295389667.347213] We cannot copy the change, falling back to memcpy [1295389667.347228] <<<<<<< osync_format_env_detect_objformat_full: (nil) [1295389667.347242] common format 0x21ba000 for objtype contact [1295389667.347255] converting to format xmlformat-contact [1295389667.347268] >>>>>>> osync_format_env_convert(0x21b9980, 0x223c0b0, 0x7f7e940eb180, 0x7f7ea5f3ec30) [1295389667.347282] >>>>>>> osync_converter_invoke(0x21bcd50, 0x7f7e940eb180, , 0x7f7ea5f3ec30) [1295389667.347296] Converter of type 1, from 0x21bb410(vcard21) to 0x21ba000(xmlformat-contact) [1295389667.347309] >>>>>>> Converter function from "vcard21" to "xmlformat-contact" - input_data: 0x7f7e940ec6d0 input_size: 2327 [1295389667.347331] >>>>>>> conv_vcard_to_xmlformat(BEGIN:VCARD VERSION:2.1 REV:20100725T123728Z N:XXXX;Markus;;; FN:Markus XXXX ADR;HOME;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:= 7/2/8;;XXXXXXXXXXXXX=0D=0ANr.=207=0D=0AStiege=202=0D=0AT=C3=BCr=208;Wien;;= 1070;=C3=96sterreich ORG:;4 Semester BDAY:19840423 EMAIL;INTERNET;ENCODING=QUOTED-PRINTABLE:ich=40markus-raab.org GEO:48.150002\;17.116667 KEY;PGP;ENCODING=BASE64: mQGiBEUgu50RBAC9i47QyffjcdSrtDya1kzDeMULtmuzA2N7KqOgeLm70tvpEYkl KAzEi0Whhf4C5uKeEnusdDiE71cBL9X5eiv5boWbk4XeoOJT+IehZmFLeTkFvg3w Uf9pvmTNGJJGLa80KTpKE8KpbmKhfgXmsyzAE+nXEg3p8Qss9MHDvPrXnwCgpaMy 0LBpXGqA3C5KtwWkMJTFcx0EAI3/e17yStTlZ3QBYC7XlEvlPQznhNSncdcLlquI 2Cx+gDSoyIAFJQXa4DC8eGrKxaWdZcyN/YF1C1gAqoOouqht3xG8Miv69tzRjcco hGeLpB7YxMX+EFHGRz0AVZsZTIB4/tK30y5oQYpuJk1j3H7JgvOsQGSTTd6QmA7X lwb8BACu9L2Vu4ph9nIH3xGLVYn+XsVtaWYfgEVbd+ku96hhJ3yPltPPl7dORlOP I8H7+C+/a46Tf8oyIn4940zN8gpCWpEQIU2z5twTpawy2wYikQRatWooj/G+ypo3 RJzjqIbk8Jrk/jseP8mFU0ijX3B3RTjZOIzVVuSFXwjzs3EAkbQ6TWFya3VzIFJh YWIgKEZvciBUdXgsIEtvbnFpIGFuZCBHUEwpIDxpY2hAbWFya3VzLXJhYWIub3Jn PohmBBMRAgAmBQJFILudAhsDBQkJZgGABgsJCAcDAgQVAggDBBYCAwECHgECF4AA CgkQYzoCH2RXaMpQkgCePOEBY6xHVogUVrDapqkwVnMwJTMAn2nwoNBC9DAWodnJ clSMnlCG0MguuQINBEUgu6IQCADBCN6DxyM14aDayo2kvNSc6T0JhjtxqPhlOACc 5RTGR5kqbMaaLqhZQcwThtHbMJhQ3JLjk50TqNPXOIRWexdoC+gPUHJwjBDKdKfX NcOn8u/OqIldRpiFnOIjDxcJQkRhOrHhP12uMbDzhqwVXoy+HX7lFQrI67jvUPkf HlQ9IKo5flbIjD9YmfU89m50avzsIIz9wrFYyBVQvR/f56UCQG3ji14pBFy/vt5W xm0hNNO0laufPV/CdN3KBGGaKkzVntEsmqW5WKw7P/qDvyTWsfr8y7obCjA+K93Q 9SbS61tkqwH6sd4CvGn5Uu+sGj2gYTrBQqo0d5v6reyezBwrAAMFB/4rUg+YEKuo ViYkvmwiHwGBiBlysjw7QHhxspXbudrFm24R8wyUCyfaUHL/8aV8Om6F6D7H+Xha hFNSKIGxLFHiag8KJmiGccEWdPLpHhia4Hfa2/GT8iXmcGNqKoy02tQvgr7ux2AF a0qe5qcUQJCfH+ff6dQR3HhUjzutts612uKlRED9zXBcowyazUVzeWS3Vy29ORKR N9rMBvLP0lZ71jeZjwBNauq1LCYZqItDzukSK68UF6XfWE5UdL1JCkwzEaxhEWr4 AC0Sjq+czGxrs/cq44uIDihPa3FV6c2SKy+++myWMOwHeq/dZ4ZhuJGQsW0O0a4N 4N5hj7tEzClHiE8EGBECAA8FAkUgu6ICGwwFCQlmAYAACgkQYzoCH2RXaMrD7ACg kCPD/1W2zfrqT6Q5Jx9MTwIf8l4An35AWFOVvKKgMUcCEjKGqvnne/Mg NOTE;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:= Besuchen=20sie=20die=20Homepage=20f=C3=BCr=20die=20aktuellen=20Daten=21= =0D=0AIch=20freue=20mich=20=C3=BCber=20Anrufe:=208:00-24:00 TEL;CELL:0650 NNNNNNNN URL:http://www.markus-XXXXXXX.org END:VCARD , 2327, 0x7f7ea5f3eb10, 0x7f7ea5f3eb28, 0x7f7ea5f3eb24, , (nil), 0x7f7ea5f3ec30) [1295389667.347352] >>>>>>> init_vcard_to_xmlformat [1295389667.347369] <<<<<<< init_vcard_to_xmlformat: 0x7f7e940e7490 [1295389667.347387] [SENSITIVE CONTENT HIDDEN] [1295389667.347534] [_read_attribute_value] escape carriage returns!! [1295389667.347563] Creating xmlformat object [1295389667.347577] >>>>>>> osync_xmlformat_new(0x7f7eb767b250, 0x7f7ea5f3ec30) [1295389667.347591] <<<<<<< osync_xmlformat_new: 0x7f7e940eee20 [1295389667.347604] parsing attributes [1295389667.347656] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940ebbc0:VERSION, 0x7f7ea5f3ec30) [1295389667.347681] Hook is: 0x1 [1295389667.347694] <<<<<<< handle_attribute: Ignored [1295389667.347708] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940eb510:REV, 0x7f7ea5f3ec30) [1295389667.347722] Hook is: 0x7f7eb766a610 [1295389667.347734] Handling Revision attribute [1295389667.347747] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Revision, 0x7f7ea5f3ec30) [1295389667.347761] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.347774] <<<<<<< osync_xmlformat_set_unsorted [1295389667.347787] <<<<<<< osync_xmlfield_new: 0x7f7e940edd80 [1295389667.347801] >>>>>>> osync_time_timestamp(20100725T123728Z) [1295389667.347815] <<<<<<< osync_time_timestamp: 20100725T123728Z [1295389667.347829] Number of parameters: 0 [1295389667.347841] <<<<<<< handle_attribute [1295389667.347897] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e95f0:N, 0x7f7ea5f3ec30) [1295389667.347913] Hook is: 0x7f7eb7669740 [1295389667.347926] Handling name attribute [1295389667.347939] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Name, 0x7f7ea5f3ec30) [1295389667.347953] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.347965] <<<<<<< osync_xmlformat_set_unsorted [1295389667.347978] <<<<<<< osync_xmlfield_new: 0x7f7e940ee3a0 [1295389667.347996] Number of parameters: 0 [1295389667.348008] <<<<<<< handle_attribute [1295389667.348021] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e62f0:FN, 0x7f7ea5f3ec30) [1295389667.348035] Hook is: 0x7f7eb7669850 [1295389667.348047] Handling formatted name attribute [1295389667.348060] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, FormattedName, 0x7f7ea5f3ec30) [1295389667.348074] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348086] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348098] <<<<<<< osync_xmlfield_new: 0x7f7e940ee130 [1295389667.348112] Number of parameters: 0 [1295389667.348124] <<<<<<< handle_attribute [1295389667.348137] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e3750:ADR, 0x7f7ea5f3ec30) [1295389667.348150] Hook is: 0x7f7eb7669540 [1295389667.348162] Handling address attribute [1295389667.348175] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Address, 0x7f7ea5f3ec30) [1295389667.348188] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348201] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348213] <<<<<<< osync_xmlfield_new: 0x7f7e940ef060 [1295389667.348231] Number of parameters: 2 [1295389667.348244] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940ef060, 0x7f7e940dd860) [1295389667.348258] Handling Location parameter TYPE [1295389667.348271] <<<<<<< handle_parameter [1295389667.348284] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940ef060, 0x7f7e940e6920) [1295389667.348298] <<<<<<< handle_parameter [1295389667.348310] <<<<<<< handle_attribute [1295389667.348323] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e9040:ORG, 0x7f7ea5f3ec30) [1295389667.348336] Hook is: 0x7f7eb766a6d0 [1295389667.348349] Handling Organization attribute [1295389667.348361] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Organization, 0x7f7ea5f3ec30) [1295389667.348375] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348388] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348400] <<<<<<< osync_xmlfield_new: 0x7f7e940efe70 [1295389667.348415] Number of parameters: 0 [1295389667.348427] <<<<<<< handle_attribute [1295389667.348451] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e8fa0:BDAY, 0x7f7ea5f3ec30) [1295389667.348465] Hook is: 0x7f7eb766a7d0 [1295389667.348477] Handling birthday attribute [1295389667.348490] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Birthday, 0x7f7ea5f3ec30) [1295389667.348503] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348516] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348528] <<<<<<< osync_xmlfield_new: 0x7f7e940efeb0 [1295389667.348542] >>>>>>> osync_time_datestamp(19840423) [1295389667.348555] <<<<<<< osync_time_datestamp: 19840423 [1295389667.348568] Number of parameters: 0 [1295389667.348581] <<<<<<< handle_attribute [1295389667.348594] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e8a70:EMAIL, 0x7f7ea5f3ec30) [1295389667.348608] Hook is: 0x7f7eb7669280 [1295389667.348625] Handling EMail attribute [1295389667.348638] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, EMail, 0x7f7ea5f3ec30) [1295389667.348652] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348664] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348677] <<<<<<< osync_xmlfield_new: 0x7f7e940f0350 [1295389667.348691] Number of parameters: 1 [1295389667.348703] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940f0350, 0x7f7e940e8fe0) [1295389667.348716] Handling Internet EMailType parameter TYPE [1295389667.348729] <<<<<<< handle_parameter [1295389667.348742] <<<<<<< handle_attribute [1295389667.348755] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940ed370:GEO, 0x7f7ea5f3ec30) [1295389667.348768] Hook is: 0x7f7eb7669050 [1295389667.348780] Handling Location attribute [1295389667.348793] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Location, 0x7f7ea5f3ec30) [1295389667.348807] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348819] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348832] <<<<<<< osync_xmlfield_new: 0x7f7e940f05e0 [1295389667.348846] Number of parameters: 0 [1295389667.348858] <<<<<<< handle_attribute [1295389667.348871] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940ed3f0:KEY, 0x7f7ea5f3ec30) [1295389667.348884] Hook is: 0x7f7eb7668c30 [1295389667.348896] Handling Key attribute [1295389667.348909] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Key, 0x7f7ea5f3ec30) [1295389667.348962] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348975] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348988] <<<<<<< osync_xmlfield_new: 0x7f7e940f07c0 [1295389667.349004] Number of parameters: 1 [1295389667.349020] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940f07c0, 0x7f7e940ed450) [1295389667.349034] <<<<<<< handle_parameter [1295389667.349046] <<<<<<< handle_attribute [1295389667.349059] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940ec4e0:NOTE, 0x7f7ea5f3ec30) [1295389667.349072] Hook is: 0x7f7eb7668d90 [1295389667.349084] Handling Note attribute [1295389667.349095] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Note, 0x7f7ea5f3ec30) [1295389667.349108] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.349120] <<<<<<< osync_xmlformat_set_unsorted [1295389667.349132] <<<<<<< osync_xmlfield_new: 0x7f7e940f1ad0 [1295389667.349145] Number of parameters: 1 [1295389667.349158] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940f1ad0, 0x7f7e940edbd0) [1295389667.349170] <<<<<<< handle_parameter [1295389667.349182] <<<<<<< handle_attribute [1295389667.349195] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940eec30:TEL, 0x7f7ea5f3ec30) [1295389667.349216] Hook is: 0x7f7eb7669330 [1295389667.349228] Handling Telephone attribute [1295389667.349240] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Telephone, 0x7f7ea5f3ec30) [1295389667.349252] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.349264] <<<<<<< osync_xmlformat_set_unsorted [1295389667.349276] <<<<<<< osync_xmlfield_new: 0x7f7e940f1da0 [1295389667.349289] Number of parameters: 1 [1295389667.349302] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940f1da0, 0x7f7e940e8be0) [1295389667.349315] Handling Type parameter TYPE [1295389667.349327] <<<<<<< handle_parameter [1295389667.349339] <<<<<<< handle_attribute [1295389667.349352] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940eed20:URL, 0x7f7ea5f3ec30) [1295389667.349364] Hook is: 0x7f7eb76647d0 [1295389667.349376] Handling Url attribute [1295389667.349388] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Url, 0x7f7ea5f3ec30) [1295389667.349401] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.349413] <<<<<<< osync_xmlformat_set_unsorted [1295389667.349425] <<<<<<< osync_xmlfield_new: 0x7f7e940f2470 [1295389667.349438] Number of parameters: 0 [1295389667.349450] <<<<<<< handle_attribute [1295389667.349462] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940eed90:END, 0x7f7ea5f3ec30) [1295389667.349477] Hook is: 0x1 [1295389667.349489] <<<<<<< handle_attribute: Ignored [1295389667.349503] >>>>>>> osync_xmlformat_sort(0x7f7e940eee20) [1295389667.349518] <<<<<<< osync_xmlformat_sort [1295389667.349565] [SENSITIVE CONTENT HIDDEN] [1295389667.349588] <<<<<<< conv_vcard_to_xmlformat: TRUE [1295389667.349603] <<<<<<< Converter function. output_size: 56, output_data: 0x7f7e940eee20 [1295389667.349631] >>>>>>> validate_xmlformat(0x7f7e940eee20, 56, 0x21bd150, 0x7f7ea5f3ec30) [1295389667.349710] ERROR: XMLFormat validation failed. [1295389667.349729] <<<<<<< validate_xmlformat: FALSE [1295389667.349742] <--- ERROR --- osync_converter_invoke: XMLFormat validation failed. [1295389667.349760] <--- ERROR --- osync_format_env_convert: XMLFormat validation failed. [1295389667.349776] >>>>>>> osync_status_update_member(0x21b7020, 0x202ab60, 3, (null), 0x7f7e940e7490) [1295389667.349790] >>>>>>> member_status(0x7f7e940efb60, (nil)) [1295389667.349808] <<<<<<< member_status [1295389667.349822] <<<<<<< osync_status_update_member [1295389667.349834] <--- ERROR --- _osync_engine_receive_change: XMLFormat validation failed. [1295389667.349850] <<<<<<< _osync_client_proxy_message_handler [1295389667.349864] Dispatching 0x7f7e9c13dec0:10(OSYNC_MESSAGE_NEW_CHANGE), timeout=0, id=0 [1295389667.349877] >>>>>>> _osync_client_proxy_message_handler(0x7f7e9c13dec0, 0x237aea0) [1295389667.349889] proxy received command 10 [1295389667.349904] Data is: 0x7f7e940e8a70, 112 |
|
From: ashish c. <ash...@gm...> - 2011-01-18 15:38:51
|
Hi all, 1)I want to know weather syncml supports email and sms syncronization or not? i am using syncml-ds-tool ,it is there in libsyncml library and i am able to syncronize phone book ,calender and notes . 2)i want to create a small applicaton using syncml api's to sync my phone book enteries .Does anyone knows from where i have to start ,and what all libraries i have to use for it. |
|
From: Daniel G. <go...@b1...> - 2011-01-17 21:04:08
|
On Sunday, January 16, 2011 07:42:25 pm deloptes wrote:
> Chris Frey wrote:
> > I'm not entirely sure that the plugin does much though. :-)
>
> this is the question
>
> someone knows what is it exactly good for?
The idea of the xsltformat plugin is to convert some-3rd-party-PIM-XML to
xmlformat-{contact,evnet,todo} and backwards by just writing XSLT-conversion
stylesheets.
The plugin just get passed as "parameter" the XSLT-conversion stylesheet file.
E.g. the google-calendar plugin was intended for something like this. Or for
qtopia devices. Anything which provides data in some XML format.
--
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970
Mail: go...@b1...
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
|
|
From: deloptes <del...@ya...> - 2011-01-17 20:39:04
|
Chris Frey wrote: > The xsltformat plugin already compiles for me, using the latest SVN. indeed! I think I haven't updated the code for a long time. when I install it, it complains [1295295858.635574] ERROR: Unable to find xslt-contact format [1295295858.635604] <--- ERROR --- osync_module_get_conversion_info: Unable to find xslt-contact format [1295295858.635717] Module get conversion error Unable to find xslt-contact format interesting :-) however there is no time to investigate further, what it is good for regards |
|
From: Chris F. <cd...@fo...> - 2011-01-17 11:16:34
|
On Sun, Jan 16, 2011 at 10:51:40PM +0100, deloptes wrote: > Thanks for replaying so fast. I use the akonadi engine or kontacts to create > two address books and sync them. Revision is applied to each side > separately. So it works in most cases. It would be better to apply some > kind of content check i.e. in slow sync but I guess it is done internally > anyway. In slow sync, you have to send all the data anyway, so revision shouldn't matter. You'll just set them all to whatever means "clean state." > I can not remember what the anchor was good for and also if it would be > useful in this plugin. I think I remember to have read something about the > slow sync ... but if something needs to be changes, my plan for such > changes is, to be done later. Anchor, which was renamed to state_db, is juse a key/value storage mechanism for the plugins. It can be used for anything. Only use it if you need it. - Chris |
|
From: deloptes <del...@ya...> - 2011-01-16 22:00:28
|
Chris Frey wrote: > Grep through the code, and I'm sure you'll find it, starting with > "FilterCategory" and proceeding backward. I'm assuming "hasCategory()" > is where the answer will be (I'm not sure of the spelling/capitalizaion > of the function anymore). This is my intention as I don't think I'll switch that fast to kde4. regards |
|
From: deloptes <del...@ya...> - 2011-01-16 21:52:08
|
Chris Frey wrote: > Do you mean you are syncing the same akonadi with itself? That would > cause problems, I guess. But if you're syncing one akonadi with a > separate one, then how could the separate revision numbers be affected? > I smell the scent of a bug here, but I don't know enough to say if it's > just in my understanding. Thanks for replaying so fast. I use the akonadi engine or kontacts to create two address books and sync them. Revision is applied to each side separately. So it works in most cases. It would be better to apply some kind of content check i.e. in slow sync but I guess it is done internally anyway. I can not remember what the anchor was good for and also if it would be useful in this plugin. I think I remember to have read something about the slow sync ... but if something needs to be changes, my plan for such changes is, to be done later. regards |
|
From: Chris F. <cd...@fo...> - 2011-01-16 19:17:34
|
On Sun, Jan 16, 2011 at 06:15:57PM +0100, deloptes wrote: > The question was how to implement the check in akonadi because akonadi has a > revision number which is incremented internally every time you edit the > record. It has ID and RemoteID, so I was not sure what I should check. I'm > still not sure the way I've implemented it is the best one, but for the > time and stage of development it is also satisfactory. The current solution > uses RemoteID for change-id and the Revision for the hash (hash = > RemoteID+"-"+Revision. I am not sure if I need to keep a tack of the > akonadiId. I don't use Akonadi, so I'm going purely on your description here, but if the Revision number is always incremented every time an entry is edited, and only then, then that is a perfectly good number to use for the hash. > However I think this is only a problem when syncing akonadi with > akonadi, because each of them increments Revision by 1 and on the next sync > it reports change, but the content is the same. Do you mean you are syncing the same akonadi with itself? That would cause problems, I guess. But if you're syncing one akonadi with a separate one, then how could the separate revision numbers be affected? I smell the scent of a bug here, but I don't know enough to say if it's just in my understanding. :-) - Chris |
|
From: Chris F. <cd...@fo...> - 2011-01-16 19:11:55
|
On Sun, Jan 16, 2011 at 07:44:16PM +0100, deloptes wrote: > Chris Frey wrote: > > > You can grep the code for "FilterCategory" and follow the trail. > > Looks like it is used to limit what categories of data are synced. > > Some handheld devices can sort their contacts and events into > > subcategories. > > does it have to be filled out? When I looked at the code briefly the other day, it seemed to take this configuration and load it into a list, and then it would check the list periodically during the sync. I think there was a function, "hasCategory()" or something in the process. Grep through the code, and I'm sure you'll find it, starting with "FilterCategory" and proceeding backward. I'm assuming "hasCategory()" is where the answer will be (I'm not sure of the spelling/capitalizaion of the function anymore). - Chris |
|
From: deloptes <del...@ya...> - 2011-01-16 18:45:22
|
Chris Frey wrote: > You can grep the code for "FilterCategory" and follow the trail. > Looks like it is used to limit what categories of data are synced. > Some handheld devices can sort their contacts and events into > subcategories. does it have to be filled out? I am looking forward to test it as in the next few days. I had this error when working on the akonadi plugin but I don't remember what it was related to. regards |
|
From: deloptes <del...@ya...> - 2011-01-16 18:42:52
|
Chris Frey wrote: > I'm not entirely sure that the plugin does much though. :-) this is the question someone knows what is it exactly good for? regards |
|
From: deloptes <del...@ya...> - 2011-01-16 18:33:23
|
Quentin Denis wrote: > Hi folks, > > may I ask you to verify this patch? Emanoil, do you now have access to > commit into the gnokii directory in SVN? Don't know, but I've updated from svn, and it seems that David ( according svn log ) applied last changes > > With this patch I removed all the warnings, except the ones related to the > calendar support. Once you have approved my contact changes, I will apply > them on calendar since it's the same code. > > However, the plugin still not listed in osynctool. I am wondering if this > is because of the remaining warnings (only related to calendar then) or > because something fundamental is missing. Any idea? For me it is now osynctool --listplugins Available plugins: file-sync evo2-sync akonadi-sync syncml-http-server syncml-http-client syncml-obex-client gnokii-sync > > I think most of the changes should be correct, but I would like to catch > your attention to the modifcations I did in the get/commit_changes > functions (gnokii_contact.c) with all the sink and format stuff changes. > Please make sure everything is okay there. > I still get this warning /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config.c: In function ‘gnokii_config_parse’: /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config.c:173: warning: ‘gn_cfg_memory_read’ is deprecated (declared at /usr/include/gnokii.h:266) /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config.c:173: warning: passing argument 1 of ‘gn_cfg_memory_read’ from incompatible pointer type /usr/include/gnokii.h:266: note: expected ‘const char **’ but argument is of type ‘char **’ /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config.c:174: warning: ‘gn_cfg_phone_load’ is deprecated (declared at /usr/include/gnokii.h:273) regards |
90 messages has been excluded from this view by a project administrator.
