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: Chris F. <cd...@fo...> - 2010-01-29 04:31:26
|
Hi, I'm sure others have handled this before, but I just can't find it. How does opensync handle international characters? The plugins, such as evolution2, don't seem to care what charset the data is in... do they assume everything is utf-8? iso? I see some bits of code to look for CHARSET in the format plugin, but this is outside the VCARD itself, and in the MIME header. If I'm passing data to opensync from a plugin, do I include these MIME headers? Thanks, - Chris |
|
From: Tino K. <tin...@ti...> - 2010-01-11 13:27:20
|
On Mon, Jan 11, 2010 at 09:20:25 +0100, Michael Banck wrote: [...] > And I am not sure about mobiles/bluetooth - what I saw so far looked > like syncevolution was more targetted at sycning with Syncml servers > over http. The mobile devices can also sync to that SyncML server over HTTP. I'm using it this way to keep my desktop, notebook and Nokia mobile phone in sync for contacts and calendar. > So while the framework might be more GNOMEish and better accesible, I > think the user-facing part has not been adressed yet. I think genesis-sync is a very useful tool. You can trigger a sync manually or let it sync periodically. It can also do special sync operations like "sync one way from server", if you messed up your local data for some reason. Regards, Tino |
|
From: Patrick O. <pat...@gm...> - 2010-01-11 09:09:18
|
On Sun, 2010-01-10 at 13:20 +0100, Bjoern Ricks wrote: > The general approach of SyncEvolution was and is to solve current > syncing problems. I describe the SyncEvolution approach as "from the ground up": start with something that can be solved, do it well and release, then continue with the next problem. I started with a SyncML client for EDS. Mac OS X Address Book was added later. A backend for XMLRPC and the Maemo calendar API were written by contributors. As of this weekend, there's also a rudimentary Akonadi backend. For 1.0, we add SyncML server support. Non-SyncML protocols might come once that works. I think the way towards non-SyncML protocols like PBAP is to wrap them in a backend and talk to the central server via SyncML as the SyncEvolution-internal protocol. > If I understood Patrick correctly SyncEvolution isn't able to > sync with different backends at the same time (at the moment). Correct. That prevents the "wrap other protocols" approach described above. But this is purely a simplification of the implementation, not a conceptual problem. We'll add it once it becomes necessary. The same applies to out-of-process backends. -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
|
From: Felix M. <fe...@de...> - 2010-01-11 09:07:34
|
Hi, Am 11.01.2010 09:20, schrieb Michael Banck: > On Sun, Jan 10, 2010 at 01:20:55PM +0100, Bjoern Ricks wrote: >> SyncEvolution is well integrated into the gnome world (e.g. using eds as >> backend). > > Well, I tried it a couple of days ago, and I would not call it "well > integrated", at least not at the application level. AFAICT, it is a CLI > application right now, which you have to trigger manually. There is a > GUI called genesis-sync, but it is not integrated with evolution or > anything else either. there are two new GUIs sync-ui-gtk and sync-ui-moblin. You have to enable them on ./configure ... > And I am not sure about mobiles/bluetooth - what I saw so far looked > like syncevolution was more targetted at sycning with Syncml servers > over http. See <http://syncevolution.org/development/sync-phone> regards Felix |
|
From: Michael B. <mb...@gm...> - 2010-01-11 08:30:25
|
On Sun, Jan 10, 2010 at 01:20:55PM +0100, Bjoern Ricks wrote: > SyncEvolution is well integrated into the gnome world (e.g. using eds as > backend). Well, I tried it a couple of days ago, and I would not call it "well integrated", at least not at the application level. AFAICT, it is a CLI application right now, which you have to trigger manually. There is a GUI called genesis-sync, but it is not integrated with evolution or anything else either. And I am not sure about mobiles/bluetooth - what I saw so far looked like syncevolution was more targetted at sycning with Syncml servers over http. So while the framework might be more GNOMEish and better accesible, I think the user-facing part has not been adressed yet. Disclaimer, I have not actually used syncevolution to sync anything yet, just tried to get rolling. Michael |
|
From: Mark E. <ma...@mp...> - 2010-01-10 21:23:06
|
Guys, I've been trying to get the sample python plugin to run through successfully. I'm coming unstuck over configuration, and was hoping for a pointer. The sample plugin sets config type as OSYNC_PLUGIN_NO_CONFIGURATION. I created a group containing the plugin, and on running osynctool --discover on the member, initially had problems in opensync/client/opensync_client.c _osync_client_handle_discover(), because there is no config. Put a test in for NULL config to get past this point, only to encounter further problems with unset config. Before I go into more detail, is there anything I need to do for a plugin with _NO_CONFIGURATION, such as set up an empty config ? Thanks Mark |
|
From: Daniel G. <go...@b1...> - 2010-01-10 18:04:11
|
On Sunday 18 October 2009 04:15:05 am Paul Eggleton wrote: > > If everyone agrees that this is "conceptually" the right thing to do, > > it should be implemented in OpenSync, and if plugins need to be adjusted, > > so be it. > > Agreed, this makes sense. > > FWIW, the patch does work for me though. > Fixed with r5993 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 |
|
From: Daniel G. <go...@b1...> - 2010-01-10 15:51:41
|
On Sunday 10 January 2010 04:35:05 pm Bjoern Ricks wrote: > Sound like an good approach. Event synchronization is much more complex Btw. by event i actually meant "calendar" .. which includes todo and event (and (v)journal) > ... Btw. is there any reason why you aren't available in the irc for weeks? > Mostly due to private reason. And the host where my IRC client was running got doomed. I'll join as soon i finished with ticket screening. 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 |
|
From: Bjoern R. <bjo...@go...> - 2010-01-10 15:35:15
|
Am 10.01.10 16:10, schrieb Daniel Gollub: > On Sunday 10 January 2010 04:07:38 pm Bjoern Ricks wrote: > >>>> I have in mind that it does only work for one objtype but >>>> >>>> >>> You mean it works only for "contact"? Or do you mean something else? >>> [...] >>> >>> >> yes that's what I had in mind. >> >> > The reason for that is simple: > We decided to focus on contact synchronization since event synchronization > would be to hard to implement in the beginning and would delay a 0.40 release > even longer. > > Of course someone else can step up and take over the event synchronization ;) > At least i focus on contact synchronization for now - once this is done i get > my hands dirty on event syncing ... > > Best Regards, > Daniel > > Sound like an good approach. Event synchronization is much more complex ... Btw. is there any reason why you aren't available in the irc for weeks? best regards Bjoern |
|
From: Daniel G. <go...@b1...> - 2010-01-10 15:10:44
|
On Sunday 10 January 2010 04:07:38 pm Bjoern Ricks wrote: > >> I have in mind that it does only work for one objtype but > >> > > > > You mean it works only for "contact"? Or do you mean something else? > > [...] > > > > yes that's what I had in mind. > The reason for that is simple: We decided to focus on contact synchronization since event synchronization would be to hard to implement in the beginning and would delay a 0.40 release even longer. Of course someone else can step up and take over the event synchronization ;) At least i focus on contact synchronization for now - once this is done i get my hands dirty on event syncing ... 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 |
|
From: Bjoern R. <bjo...@go...> - 2010-01-10 15:07:47
|
>> I have in mind that it does only work for one objtype but >> > You mean it works only for "contact"? Or do you mean something else? > [...] > yes that's what I had in mind. > Best Regards, > Daniel > > |
|
From: Daniel G. <go...@b1...> - 2010-01-10 13:29:17
|
On Sunday 10 January 2010 01:49:19 pm Bjoern Ricks wrote: > taking part at the KDE PIM meeting was quite a good motivation to > restart working on OpenSync and to write some mails on the list. It > isn't good that the communication stopped at the last month again. First > I would like to say that OpenSync is still not dead and that's Daniels > opinion too. ack [...] > But I would like to discuss how we as the opensync community can speed > up development and which things/bugs of the current development cycle > are important. The current issues can be found at > http://opensync.org/query?status=assigned&status=new&status=reopened&group= > status&milestone=OpenSync+0.40 See the most important issues fixes asap > would be a big step forward but I completely lost the overview which > features are important and have to be fixes to get the plugins back on > track. Yeah thats similar to me. I tried to hunt down the list which required my attention. Like the missing exported function of the osync_queue_cross_link function which broke evo2-sync and other plugins running in a seperated process. This is hopefully fixed, could someone verify that evo2-sync is working? #1190 It would be great if someone could screen which are assigned to 0.40 Milestone and reprioritize them. And try to reproduce them ... tickets which are assigend to "OpenSync" component and are plugin specific issues should get assigned to it's plugin component so we get a better overview. I start now screening those tickets which are still belong to "OpenSync" component ... but it would be nice if others which want to contribute to OpenSync, but can't contribute code, would help keeping "OpenSync 0.40" milestone clean: http://opensync.org/query?status=assigned&status=new&status=reopened&group=status&component=OpenSync&order=priority&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&milestone=OpenSync+0.40 Also those who have filed tickets in the past could help: please check if your bug is still reproducible with latest trunk. And if you think your bug needs special attention please rise the priority (but don't over do this please!) > I guess e.g. that the syncml plugin doesn't work without fixing the > guid mapping bug > http://opensync.org/ticket/1105 I guess #1105 is already fixed and is a duplicate of #1161 We filed two tickets for the same problem .. but i need to go through this in more details. It would be great if Michael could help me in clarifying that this <Map> problem is already solved. > Which bugs have also to be fixed to get > an opensync version that is usable? What's the current status of the > capabilities? I'm still need to get a description done how the capsformat stuff is supposed to work. Handling of Capability Parameter is not implemented. But it's not used yet anyway ... so maybe not a blocker for 0.40 > I have in mind that it does only work for one objtype but You mean it works only for "contact"? Or do you mean something else? [...] 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 |
|
From: Daniel G. <go...@b1...> - 2010-01-10 13:17:13
|
On Sunday 10 January 2010 01:20:55 pm Bjoern Ricks wrote: > In the opposite a cool feature of SyncEvolution > is the scriptable data conversion using libsynthesis. > I'm also very interested in this. That's also the reason why I spent so much time in making sure that we can support multiple common formats (e.g XMLFormat, and others ...). The idea is to make use of libsynthesis data conversion code for better support of the vformats ... and keep XMLFormat for compatibly reason or more simpler API for plugins which don't have vformats. (No, xmlformat is not going to be dropped ... at least as long plugins still using it. If there is one way a better alternative we can easily switch to it) 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 |
|
From: Bjoern R. <bjo...@go...> - 2010-01-10 12:56:44
|
taking part at the KDE PIM meeting was quite a good motivation to restart working on OpenSync and to write some mails on the list. It isn't good that the communication stopped at the last month again. First I would like to say that OpenSync is still not dead and that's Daniels opinion too. Because of my new job I am going to participate in porting KDE PIM (especially akonadi) to mobile platforms. Therefore I am really sure that there will be an OpenSync plugin for akonadi in the future ;-) The KDE PIM guys haven't decided to use any other sync solution (e.g. SyncEvolution) yet. So OpenSync still has a chance to be THE sync solution on KDE desktops (and also on mobiles). But I would like to discuss how we as the opensync community can speed up development and which things/bugs of the current development cycle are important. The current issues can be found at http://opensync.org/query?status=assigned&status=new&status=reopened&group=status&milestone=OpenSync+0.40 See the most important issues fixes asap would be a big step forward but I completely lost the overview which features are important and have to be fixes to get the plugins back on track. I guess e.g. that the syncml plugin doesn't work without fixing the guid mapping bug http://opensync.org/ticket/1105 Which bugs have also to be fixed to get an opensync version that is usable? What's the current status of the capabilities? I have in mind that it does only work for one objtype but I am not sure. It would also be great if we can collect some opinions why we lost so much people again and again and how to improve that. I do have an opinion and also some reasons about that but I really don't want to see that there is no discussion on the list and in the irc if Daniel and me can't spend time to write code. regards Bjoern |
|
From: Bjoern R. <bjo...@go...> - 2010-01-10 12:45:23
|
Hi, I am currently at the KDE PIM Meeting and yesterday I attended to a talk about SyncEvolution and syncing in general. Patrick Ohly had presented some slides about SyncEvolution and I also talked to him in private. Afterwards it became clear to me that there are some differences between OpenSync and SyncEvolution that I want to share with the list. Patrick please correct me if I am wrong in any comment and also if I forgot some features. The general approach of SyncEvolution was and is to solve current syncing problems. That's completely different to OpenSync. OpenSync wants to be a general framework for mostly all PIM synchronization problems. Therefore our architecture is more complicated and difficult to understand. SyncEvolution is based on syncml and uses syncml to communicate with their peers. In OpenSync syncml is only one possible client. SyncEvolution also has a dbus daemon and provides a GUI. OpenSync is only concentrating on the framework/library and does provide osynctool for testing. There is no dbus integration in OpenSync at all. SyncEvolution is well integrated into the gnome world (e.g. using eds as backend). If I understood Patrick correctly SyncEvolution isn't able to sync with different backends at the same time (at the moment). The OpenSync architecture always supported different backends/peers (e.g. evolution and gnokii) and is loosely coupled to syncml. With OpenSync it is also possible to sync different backends/peers at the same time because of the sync group feature. In OpenSync the sync plugin are able to run in different threads, processes, etc. OpenSync contains an IPC layer and plugins don't have to care about that in detail. This feature is completely missing in SyncEvolution. In my opinion this is a big advantage of OpenSync. In the opposite a cool feature of SyncEvolution is the scriptable data conversion using libsynthesis. regards Bjoern |
|
From: Daniel G. <go...@b1...> - 2010-01-10 11:54:12
|
On Sunday 10 January 2010 12:46:02 pm Mark Ellis wrote: > > If you like i can give you write-access to opensync trunk directory to > > incoperate python wrapper changes directly, if you like. Just let me > > know whats your login on the OpenSync Trac. > > > > Cool, trac login is markellis > Ok, give it a try. Set read-write permissions for /plugins/python-module and /trunk Checkin and checkout is via https://svn.opensync.org (No svn+ssh:// or something like that ...) If you have any troubles committing let us know. 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 |
|
From: Mark E. <ma...@mp...> - 2010-01-10 11:46:12
|
On Sun, 2010-01-10 at 12:13 +0100, Daniel Gollub wrote: > Hi Mark, > > On Sunday 10 January 2010 10:37:58 am Mark Ellis wrote: > [...] > > I'd be delighted to take a look at the python wrappers, I started having > > a stab already. The other python wrappers I work with are built with > > pyrex rather than swig, but it looks like the API can be updated without > > too much of a learning curve. > > If you like i can give you write-access to opensync trunk directory to > incoperate python wrapper changes directly, if you like. Just let me know > whats your login on the OpenSync Trac. > Cool, trac login is markellis > > > > I was also going to try and add some wrappers to libwbxml, does anyone > > who works on that hang around here ? > > > > Michael Bell is maintaining on libwbxml. > > Best Regards, > Daniel > |
|
From: Daniel G. <go...@b1...> - 2010-01-10 11:17:52
|
Hi Mark, On Thursday 31 December 2009 07:23:14 pm Mark Ellis wrote: > Hi opensync-devel > > I'm hoping this list is used, since I haven't seen much activity .... Yeah, as Björn already mentioned some of us were busy with private things. [...] > We started looking again at later opensync versions after the 0.39 > release, and I've attached a patch to the python plugin against trunk. I > am reasonably confident with what I've done, but haven't actually been > able to test it since the libopensync python wrappers from trunk aren't > behaving. I guess they are lagging somewhat behind the api changes. Your patch looks good to me. Could you register on OpenSync Trac on https://www.opensync.org and let me know your login. So i'll grant you write- access to the python-module plugin if you like. > > I may have a look at fixing up the python wrappers, but need to get to > grips with the opensync internals more first. Is anyone working on this > at the moment ? Any pointers ? As Björn already mentioned there is no one looking at the python wrapper. It would be great if you could take a look at it. Since Björn and I are busy enough with the actual C API ... Thanks for your interested and contribution to the OpenSync project! 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 |
|
From: Daniel G. <go...@b1...> - 2010-01-10 11:14:11
|
Hi Mark, On Sunday 10 January 2010 10:37:58 am Mark Ellis wrote: [...] > I'd be delighted to take a look at the python wrappers, I started having > a stab already. The other python wrappers I work with are built with > pyrex rather than swig, but it looks like the API can be updated without > too much of a learning curve. If you like i can give you write-access to opensync trunk directory to incoperate python wrapper changes directly, if you like. Just let me know whats your login on the OpenSync Trac. > > I was also going to try and add some wrappers to libwbxml, does anyone > who works on that hang around here ? > Michael Bell is maintaining on libwbxml. 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 |
|
From: Mark E. <ma...@mp...> - 2010-01-10 09:38:08
|
Hi Bjoern ! Ah yes, real life gets in the way sometimes. I'd be delighted to take a look at the python wrappers, I started having a stab already. The other python wrappers I work with are built with pyrex rather than swig, but it looks like the API can be updated without too much of a learning curve. I was also going to try and add some wrappers to libwbxml, does anyone who works on that hang around here ? Thanks Mark On Sun, 2010-01-10 at 09:28 +0100, Bjoern Ricks wrote: > Sorry for the late reply. Currently the development of opensync stucks > again, because Daniel and me haven't had much time to work on it. This > list is correct of course. Your patch seems to be correct and feel > free to commit it to opensync svn. I guess Daniel will be happy to > give you access to our codebase. We currently don't have a maintainer > for the python-module therefore it would be great if you can step in > and take up the maintenance of it. The problem of the python api in > opensync is that there is no developer with python knowledge. I > changed e.g. the opensync list api in the past but don't had any clue > how to convert that to the python api. > > regards > Bjoern > > Am 31.12.09 19:23, schrieb Mark Ellis: > > Hi opensync-devel > > > > I'm hoping this list is used, since I haven't seen much activity .... > > > > I'm involved with the synce project, that uses the python plugin to sync > > against windows mobile devices. > > > > We started looking again at later opensync versions after the 0.39 > > release, and I've attached a patch to the python plugin against trunk. I > > am reasonably confident with what I've done, but haven't actually been > > able to test it since the libopensync python wrappers from trunk aren't > > behaving. I guess they are lagging somewhat behind the api changes. > > > > I may have a look at fixing up the python wrappers, but need to get to > > grips with the opensync internals more first. Is anyone working on this > > at the moment ? Any pointers ? > > > > Thanks > > Mark > > > > > > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > > > _______________________________________________ > > Opensync-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensync-devel > > > |
|
From: Bjoern R. <bjo...@go...> - 2010-01-10 08:29:11
|
Sorry for the late reply. Currently the development of opensync stucks again, because Daniel and me haven't had much time to work on it. This list is correct of course. Your patch seems to be correct and feel free to commit it to opensync svn. I guess Daniel will be happy to give you access to our codebase. We currently don't have a maintainer for the python-module therefore it would be great if you can step in and take up the maintenance of it. The problem of the python api in opensync is that there is no developer with python knowledge. I changed e.g. the opensync list api in the past but don't had any clue how to convert that to the python api. regards Bjoern Am 31.12.09 19:23, schrieb Mark Ellis: > Hi opensync-devel > > I'm hoping this list is used, since I haven't seen much activity .... > > I'm involved with the synce project, that uses the python plugin to sync > against windows mobile devices. > > We started looking again at later opensync versions after the 0.39 > release, and I've attached a patch to the python plugin against trunk. I > am reasonably confident with what I've done, but haven't actually been > able to test it since the libopensync python wrappers from trunk aren't > behaving. I guess they are lagging somewhat behind the api changes. > > I may have a look at fixing up the python wrappers, but need to get to > grips with the opensync internals more first. Is anyone working on this > at the moment ? Any pointers ? > > Thanks > Mark > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > > > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel > |
|
From: Mark E. <ma...@mp...> - 2009-12-31 18:23:37
|
Hi opensync-devel I'm hoping this list is used, since I haven't seen much activity .... I'm involved with the synce project, that uses the python plugin to sync against windows mobile devices. We started looking again at later opensync versions after the 0.39 release, and I've attached a patch to the python plugin against trunk. I am reasonably confident with what I've done, but haven't actually been able to test it since the libopensync python wrappers from trunk aren't behaving. I guess they are lagging somewhat behind the api changes. I may have a look at fixing up the python wrappers, but need to get to grips with the opensync internals more first. Is anyone working on this at the moment ? Any pointers ? Thanks Mark |
|
From: Chris F. <cd...@fo...> - 2009-12-09 22:25:16
|
On Wed, Dec 09, 2009 at 01:51:53PM -0800, Theodore Charles III wrote: > As of right now, barry uses the Opensync 0.22 API. I was reading > something in the FAQ in that the future versions of Opensync API will > not have calendar syncing available. I quote: > > Why there will be no calendar syncing with 0.3x or 0.40? > Because format (vFormat, xmlFormat) plugins are not complete before > these releases due the fact that iCalendar and vCalendar handling is > really complex. Conversion problems between RRULE's complicates the > implementation. There is no Timezone handling at all in vCalendar. 90% > all sync setups request by users involve iCalendar <-> vCalendar syncing. This is an opensync FAQ question, so I'll CC the opensync list as well. http://opensync.org/wiki/trunk/faq#why-no-calendar While timezone support is indeed not available, as far as I know, I didn't think that it was a show stopper. Version 0.22 doesn't have timezone support either. > So, as far as the barry project goes, will this mean that barry will > continue to use the 0.22 API for synchronizing? Barry has both an 0.22 plugin and an 0.4x plugin. The 0.4x plugin tracks the current opensync devel tree relatively closely. You are free to use either, but understand that there are unique issues with each. i.e. 0.22 lacks capability support, and sometimes requires a fresh sync to recover from hang problems and 0.4x is not yet released, and is still in development. - Chris |
|
From: Ian M. <ian...@ca...> - 2009-12-01 10:19:21
|
I believe you are seeing this problem: http://opensync.org/ticket/1190 2009/11/30 Nicolas <pr...@fr...>: > Hi, > > Here, my output console : > > Received an entry 116 (vcard30) from member 2 (barry-sync). Changetype > ADDED > contact sink of member 2 of type barry-sync just sent all changes > Main sink of member 2 of type barry-sync just sent all changes > ERROR: Timeout. > EXIT_ERROR: _osync_send_timeout_response: cannot find reply queue to > send timeout error > Main sink of member 1 of type evo2-sync just sent all changes > All clients sent changes or error > ERROR: Broken Pipe > [...] > ERROR: Broken Pipe > All changes got mapped > ERROR: Broken Pipe > [...] > ERROR: Broken Pipe > All conflicts have been reported > ERROR: Broken Pipe > [...] > ERROR: Broken Pipe > All changes got multiplied > ERROR: Broken Pipe > [...] > ERROR: Broken Pipe > All changes got prepared for write > ERROR: Broken Pipe > > Synchronization Forecast Summary: > > ObjType: contact > Member 1: Adding(112) Modifying(0) Deleting(0) > Member 2: Adding(1) Modifying(0) Deleting(0) > > Do you want to continue the synchronization? (N/y): ERROR: Broken Pipe > ERROR: Broken Pipe > ERROR: Broken Pipe > [...] > > > This issue is always reproductible :( > > I don't understand. > > > If you have clues to help to debug this ; I could post a little patch... > > > I'll post SYNC traces into your bugtracker. > > > Regards, > > Nicolas > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel > |
|
From: Nicolas <pr...@fr...> - 2009-11-30 22:28:48
|
Hi, Here, my output console : Received an entry 116 (vcard30) from member 2 (barry-sync). Changetype ADDED contact sink of member 2 of type barry-sync just sent all changes Main sink of member 2 of type barry-sync just sent all changes ERROR: Timeout. EXIT_ERROR: _osync_send_timeout_response: cannot find reply queue to send timeout error Main sink of member 1 of type evo2-sync just sent all changes All clients sent changes or error ERROR: Broken Pipe [...] ERROR: Broken Pipe All changes got mapped ERROR: Broken Pipe [...] ERROR: Broken Pipe All conflicts have been reported ERROR: Broken Pipe [...] ERROR: Broken Pipe All changes got multiplied ERROR: Broken Pipe [...] ERROR: Broken Pipe All changes got prepared for write ERROR: Broken Pipe Synchronization Forecast Summary: ObjType: contact Member 1: Adding(112) Modifying(0) Deleting(0) Member 2: Adding(1) Modifying(0) Deleting(0) Do you want to continue the synchronization? (N/y): ERROR: Broken Pipe ERROR: Broken Pipe ERROR: Broken Pipe [...] This issue is always reproductible :( I don't understand. If you have clues to help to debug this ; I could post a little patch... I'll post SYNC traces into your bugtracker. Regards, Nicolas |
90 messages has been excluded from this view by a project administrator.
