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: Jelle de J. <jel...@po...> - 2009-09-28 12:58:55
|
On 09/28/09 03:53, Chris Frey wrote: > On Sun, Sep 27, 2009 at 09:13:43PM +0200, Jelle de Jong wrote: >> syncml-ldap plugin that can sync contacts with an openldap server >> http://www.opensync.org/ticket/1069 > > According to my understanding of how opensync works, this is > two plugins, no? A syncml plugin + opensync + an LDAP plugin. > > And don't things things already exist, with varying 50% to 90% > completion? Most basic blocks do exist but are not available as working libraries with API's for GUI/CLI developers. I have been able to pull out the contact, email, calender information from my SyncML capable Nokia telephone with bluetooth. However this information alone is still useless. I got an imap, caldav and openldap server. (we are not talking about MUA clients) I would like to see that the OpenSync tools that gather the data with SyncML and then login into the respective services of the server(s) and synchronize the data, without going pass a MUA. There should also be libraries available that do imap, caldav and openldap. These blocks/libraries/documentation needs to be improved where necessary to make the above all work. Then a GNOME/KDE/XFCE/CLI/whatever developer can use this to make a perfect GUI for the end user that can input the servers accounts and connection information and make the synchronization action happen. This can all be done with bluetooth or the other connection that SycML/OpenSync supports. Would this be something the OpenSync team is willing to do? Best regards, Jelle de Jong |
|
From: Chris F. <cd...@fo...> - 2009-09-28 02:18:08
|
On Sun, Sep 27, 2009 at 12:58:02PM +0200, Daniel Gollub wrote:
> Chris, could you incoperate the changes for XDG_{CONFIG,DATA,CACHE}_HOME?
>
> In the beginning i guess it would be fine if you start with XDG_CONFIG_HOME
> and make this the default opensync config directory for 0.40
>
> e.g. ~/.config/opensync/0.40/
$XDG_CONFIG_HOME by itself shouldn't be too hard.
Anyone know if there is a library for this kind of stuff, such as for
$XDG_CONFIG_DIRS searching? This isn't hard programming, but looks like
the kind of thing that should be implemented once, and I don't want to
reinvent the wheel.
- Chris
|
|
From: Chris F. <cd...@fo...> - 2009-09-28 02:03:51
|
On Sun, Sep 27, 2009 at 09:13:43PM +0200, Jelle de Jong wrote: > syncml-ldap plugin that can sync contacts with an openldap server > http://www.opensync.org/ticket/1069 According to my understanding of how opensync works, this is two plugins, no? A syncml plugin + opensync + an LDAP plugin. And don't things things already exist, with varying 50% to 90% completion? - Chris |
|
From: Jelle de J. <jel...@po...> - 2009-09-27 19:30:13
|
Hello everybody, It has been six months since my original feature request, and it has been a month ago since our last contacts. I have been talking with the NLnet organisation about making a project with a sponsert bounty and also donated my own 2500 euro grant for this. There are of course also other people that would like to see these synchronization building blocks developed. I estimated that it would take around 10.000 euro. How do you guys feel about this? Is somebody willing to step up for this bounty :D What do you guys need? summary: http://www.opensync.org/ticket/1073 syncml-ldap plugin that can sync contacts with an openldap server http://www.opensync.org/ticket/1069 syncml-caldav plugin that can sync calenders with a caldav server http://www.opensync.org/ticket/1070 syncml-imap plugin that can synchronize emails with a imap server http://www.opensync.org/ticket/1071 syncml-filters plugin that can synchronize mailfilters with a managesieve (dovecot) server http://www.opensync.org/ticket/1072 Thanks in advance, Jelle de Jong |
|
From: Daniel G. <go...@b1...> - 2009-09-27 10:56:24
|
On Sunday 27 September 2009 12:30:21 pm Pawel Kot wrote:
> > Good question. I think plenty of software already uses it,
> > i've been changing some files under it. Then again, there
> > are tons of projects that still don't use it. Generally
> > XDG stuff has been good, for example the xdg-open has
> > made life much easier in distro level when integrating
> > software together.
> >
> > So would it be then like:
> >
> > ~/.config/opensync/0.40
> >
> > as they don't seem to address the actual problem in hand, which
> > is versions related.
>
> That's right. However I would see also usage of XDG_DATA_HOME or
> XDG_CACHE_HOME (probably the former one) for storing non-config data
> like all *.db files.
>
> > Any idea why it would make much difference to have .config
> > prefix? Does some generic tool already use it regardless
> > of actual config writers?
>
> Well, I don't know actually origins but it definitely cleans up the
> home directory. To me there's no obvious quality advantage, but
> following guidelines you know where to find configuration
> (XDG_CONFIG_HOME), other permanent user data (XDG_DATA_HOME) and
> temporary user data (XDG_CACHE_HOME).
>
Chris, could you incoperate the changes for XDG_{CONFIG,DATA,CACHE}_HOME?
In the beginning i guess it would be fine if you start with XDG_CONFIG_HOME
and make this the default opensync config directory for 0.40
e.g. ~/.config/opensync/0.40/
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: Paul E. <blu...@bl...> - 2009-09-27 10:42:32
|
Hi all, I've just recently changed opie-sync to do the connection to the device in a main sink rather than checking if it needed to be done within each objtype sink. However I have come accross some behaviour that I don't understand. It seems the main sink only connects after all of the objtype sinks have connected. In my case I need to connect to the device, and then after that I need to determine for each objtype whether slow-sync is required; this latter task needs to be done at the connect stage I believe. I don't think the way it works now will let me do that without going back to having the main connect logic in each objtype sink's connect function; but if I do go back I can't retrieve a few stored values that I am (at the moment) putting into the main sink's state db. I assume this connect order is intentional. If so, what is the reason for doing it this way? Thanks, Paul |
|
From: Pawel K. <paw...@gm...> - 2009-09-27 10:30:47
|
Hi, On Sun, Sep 27, 2009 at 12:03, Juha Tuomala <Juh...@ik...> wrote: > > > > On Sun, 27 Sep 2009, Pawel Kot wrote: >> Maybe I'm putting the cat against the pigeons but why not follow >> freedesktop.org standards starting from 0.40? >> http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html > > Good question. I think plenty of software already uses it, > i've been changing some files under it. Then again, there > are tons of projects that still don't use it. Generally > XDG stuff has been good, for example the xdg-open has > made life much easier in distro level when integrating > software together. > > So would it be then like: > > ~/.config/opensync/0.40 > > as they don't seem to address the actual problem in hand, which > is versions related. That's right. However I would see also usage of XDG_DATA_HOME or XDG_CACHE_HOME (probably the former one) for storing non-config data like all *.db files. > Any idea why it would make much difference to have .config > prefix? Does some generic tool already use it regardless > of actual config writers? Well, I don't know actually origins but it definitely cleans up the home directory. To me there's no obvious quality advantage, but following guidelines you know where to find configuration (XDG_CONFIG_HOME), other permanent user data (XDG_DATA_HOME) and temporary user data (XDG_CACHE_HOME). take care, -- Pawel Kot |
|
From: Juha T. <Juh...@ik...> - 2009-09-27 10:03:41
|
On Sun, 27 Sep 2009, Pawel Kot wrote: > Maybe I'm putting the cat against the pigeons but why not follow > freedesktop.org standards starting from 0.40? > http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html Good question. I think plenty of software already uses it, i've been changing some files under it. Then again, there are tons of projects that still don't use it. Generally XDG stuff has been good, for example the xdg-open has made life much easier in distro level when integrating software together. So would it be then like: ~/.config/opensync/0.40 as they don't seem to address the actual problem in hand, which is versions related. Any idea why it would make much difference to have .config prefix? Does some generic tool already use it regardless of actual config writers? Tuju -- Ajatteleva ihminen tarvitsee unta. |
|
From: Pawel K. <paw...@gm...> - 2009-09-27 09:50:26
|
Hi, On Sun, Sep 27, 2009 at 07:43, Chris Frey <cd...@fo...> wrote: > After giving this some more thought, I've found that there are 3 options > for naming the 0.40 directory: > > 1) use the library soname (~/.libopensync1) > > 2) use the syncgroup.conf version (~/.opensync/1.0) > > 3) use the stable release series version (~/.opensync/0.40) Maybe I'm putting the cat against the pigeons but why not follow freedesktop.org standards starting from 0.40? http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html take care, -- Pawel Kot |
|
From: <Juh...@ik...> - 2009-09-27 09:19:46
|
On Sun, 27 Sep 2009, Daniel Gollub wrote: > On Sunday 27 September 2009 07:43:56 am Chris Frey wrote: >> 3) use the stable release series version (~/.opensync/0.40) >> >> I like option #3. It is clear to the user, and this is a user >> I'll go with option #3 unless notified. > > I'm also fine with #3 - let's give it a try. Yep, #3 sounds like users wouldn't rise their eyebrows for it. Tuju -- Ajatteleva ihminen tarvitsee unta. |
|
From: Chris F. <cd...@fo...> - 2009-09-27 08:02:02
|
On Sun, Sep 27, 2009 at 09:49:09AM +0200, Daniel Gollub wrote: > Ok, sound good to me - could you implement (and commit) the required changes? > And do basic testing for 0.22 as well? Certainly. I don't plan on making any changes to 0.22 at all, but I do need to test to make sure a 0.40 subdirectory doesn't confuse 0.22. I don't think 0.22 does a recursive search for "group?" directories, does it? I'll test though. Thanks, - Chris |
|
From: Daniel G. <go...@b1...> - 2009-09-27 07:48:48
|
On Sunday 27 September 2009 07:43:56 am Chris Frey wrote: > 3) use the stable release series version (~/.opensync/0.40) > > I like option #3. It is clear to the user, and this is a user > oriented directory. Also, a version like 0.4x or 0.40 maintains > the goal of keeping 0.4x versions compatible with each other, > while letting the syncgroup.conf version work as designed. > > I'll go with option #3 unless notified. > I'm also fine with #3 - let's give it a try. 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...> - 2009-09-27 07:47:48
|
On Sunday 27 September 2009 07:37:46 am Chris Frey wrote: > On Sat, Sep 26, 2009 at 09:26:43AM +0200, Daniel Gollub wrote: > > One thing which didn't got mentioned yet is: OSyncUpdater > > What do you think of this logic: > > Since osync_group_env_load_groups() is in charge of creating the new > default .opensync directory if it does not exist, why not let it copy the > existing group* directories into the new 0.40 directory? > > This creates a nice backup, as well as gives 0.40 a starting point > of configurations. > > It also copies the existing behaviour. Under current 0.39 behaviour, > the user expects to be able to upgrade. If we just copy everything over > to 0.40, we retain this behaviour while leaving 0.22 alone. > > It is also easy to implement. :-) Ok, sound good to me - could you implement (and commit) the required changes? And do basic testing for 0.22 as well? 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: Chris F. <cd...@fo...> - 2009-09-27 05:44:33
|
On Sat, Sep 26, 2009 at 11:28:20PM -0400, Chris Frey wrote: > On Sat, Sep 26, 2009 at 02:40:51PM +0300, Juh...@ik... wrote: > > On Fri, 25 Sep 2009, Chris Frey wrote: > > > - HOME config > > > 0.22: ~/.opensync > > > 0.40: ~/.opensync > > > > > > I like the suggestion in #890. At least the 0.40 directory. Even a > > > ~/.libopensync1 directory would be good... actually that's probably best. > > > > Please, keep the versions under the .opensync dir if this gets > > implmented. There is already enough kakofonia in users' home dirs > > let's make sure that we don't add that mess. > > I don't care too much either way, as long as the defaults are separate. After giving this some more thought, I've found that there are 3 options for naming the 0.40 directory: 1) use the library soname (~/.libopensync1) 2) use the syncgroup.conf version (~/.opensync/1.0) 3) use the stable release series version (~/.opensync/0.40) I like option #3. It is clear to the user, and this is a user oriented directory. Also, a version like 0.4x or 0.40 maintains the goal of keeping 0.4x versions compatible with each other, while letting the syncgroup.conf version work as designed. I'll go with option #3 unless notified. - Chris |
|
From: Chris F. <cd...@fo...> - 2009-09-27 05:38:26
|
On Sat, Sep 26, 2009 at 09:26:43AM +0200, Daniel Gollub wrote: > One thing which didn't got mentioned yet is: OSyncUpdater What do you think of this logic: Since osync_group_env_load_groups() is in charge of creating the new default .opensync directory if it does not exist, why not let it copy the existing group* directories into the new 0.40 directory? This creates a nice backup, as well as gives 0.40 a starting point of configurations. It also copies the existing behaviour. Under current 0.39 behaviour, the user expects to be able to upgrade. If we just copy everything over to 0.40, we retain this behaviour while leaving 0.22 alone. It is also easy to implement. :-) Thoughts? - Chris |
|
From: Chris F. <cd...@fo...> - 2009-09-27 03:29:03
|
On Sat, Sep 26, 2009 at 02:40:51PM +0300, Juh...@ik... wrote: > On Fri, 25 Sep 2009, Chris Frey wrote: > > - HOME config > > 0.22: ~/.opensync > > 0.40: ~/.opensync > > > > I like the suggestion in #890. At least the 0.40 directory. Even a > > ~/.libopensync1 directory would be good... actually that's probably best. > > Please, keep the versions under the .opensync dir if this gets > implmented. There is already enough kakofonia in users' home dirs > let's make sure that we don't add that mess. I don't care too much either way, as long as the defaults are separate. > Also, it doesn't come into my mind, that what other lib would have > it's so-name also in dotdir name. Why not keep it as more intuitive > like plain .opensync is? That's what users see and the package > versions, not the so names or any symbol names either. I wasn't thinking in terms of the user accessing this directory so much, but it's a good point. I was thinking in programmer terms. :-) - Chris |
|
From: <Juh...@ik...> - 2009-09-26 12:09:27
|
On Fri, 25 Sep 2009, Chris Frey wrote: > - HOME config > 0.22: ~/.opensync > 0.40: ~/.opensync > > I like the suggestion in #890. At least the 0.40 directory. Even a > ~/.libopensync1 directory would be good... actually that's probably best. Please, keep the versions under the .opensync dir if this gets implmented. There is already enough kakofonia in users' home dirs let's make sure that we don't add that mess. Also, it doesn't come into my mind, that what other lib would have it's so-name also in dotdir name. Why not keep it as more intuitive like plain .opensync is? That's what users see and the package versions, not the so names or any symbol names either. Tuju -- Ajatteleva ihminen tarvitsee unta. |
|
From: Chris F. <cd...@fo...> - 2009-09-26 08:24:52
|
On Sat, Sep 26, 2009 at 09:26:43AM +0200, Daniel Gollub wrote: > > - pkg-config: > > > > 0.22: opensync-1.0.pc > > 0.40: libopensync.pc (should be libopensync1.pc, but no biggie) > > Need to check why we took libopensync.pc not libopensync1.pc .... Let me know if you find out. I can patch this if needed. > > If this were implemented, it would be possible to write applications > > that support both libraries at runtime, which I'm working on right now. > > Hmm interesting ... do you really think it's worth to stay with 0.22 for long? Well, depending on when 0.40 comes out, there will probably still be 6 months before it gets included in fast-moving distros such as Ubuntu and Fedora. And users often upgrade sometime after that. And some users may need the 0.22 plugin even while using 0.40 for other things. Just a guess. Maybe my fears are for nothing, but I certainly plan on having both installed just to support users, and it would be a pain if I kept clobbering my own test configs. :-) > And i'm also not quite sure if it's really worth to put so much effort in > supporting several APIs - at least so early ... Well, 0.22 is already there... if 0.22 and 0.40 don't conflict then 0.22 is just there as a happy backup, maybe even for OSyncUpdater. I wouldn't look at it as unnecessary API support... 0.22 won't go away too fast, I think. > But if someone wants to take care about this i'm not going to stop her/him ... > At least i'm going to concentrate on a "simple" update-path for now ... So just to be clear, if I come up with a patch for OSyncUpdater, I can change 0.40's default config directory from ~/.opensync to ~/.libopensync1 ? Thanks, - Chris |
|
From: Daniel G. <go...@b1...> - 2009-09-26 07:25:04
|
On Saturday 26 September 2009 05:48:53 am Chris Frey wrote: > Hi, > > I posted about this before, and was pointed to the following ticket: > > http://opensync.org/ticket/890 > > It appears that this ticket suggestion was not used. So there is the > possibility of configurations conflicting between 0.22 and 0.4x. > > Fortunately, the following conflicts are resolved: > > - pkg-config: > > 0.22: opensync-1.0.pc > 0.40: libopensync.pc (should be libopensync1.pc, but no biggie) Need to check why we took libopensync.pc not libopensync1.pc .... > > - include directories: > > 0.22: /usr/include/opensync-1.0 > 0.40: /usr/include/libopensync1 ok > > - library names: > > 0.22: libopensync.so.0 and libosengine.so.0 > 0.40: libopensync.so.1 ok > > - plugin directory: > > 0.22: /usr/lib/opensync/plugins > 0.40: /usr/lib/libopensync1/plugins ok > > Unfortunately: > > - HOME config > > 0.22: ~/.opensync > 0.40: ~/.opensync Yeahh ... thats tricky .. > > I like the suggestion in #890. At least the 0.40 directory. Even a > ~/.libopensync1 directory would be good... actually that's probably best. > > Since all configuration is supposed to be done through opensync anyway, > the actual name of this directory shouldn't matter, and should, in my > opinion, get renamed as the API and config formats change. Good point. > > If this were implemented, it would be possible to write applications > that support both libraries at runtime, which I'm working on right now. Hmm interesting ... do you really think it's worth to stay with 0.22 for long? > As it is, I'll likely have to use non-standard configdirs for my app, > which will separate it from all other opensync apps. Right - but thats possible. You can set osync_group_set_config_dir() or so. At least thats better then writing your own Synchronization Engine from scratch ;) > This is ok too, > I suppose, but not ideal. [...] One thing which didn't got mentioned yet is: OSyncUpdater OSyncUpdater is an API to perform configurtaion transations from 0.22 -> 0.40 (and of course in a general fashion X.XX -> Y.YY). This OSyncUpdater API needs to get called by the OpenSync Applications/("Frontends"). See http://article.gmane.org/gmane.comp.misc.opensync.devel/2498 Currently this implementation would use ~/.opensync/groupX/ and overwrite all configuration with the updated configuraiton format. (In advance a backup would get created by the API - in case anything went wrong on conversion ...) The OSyncUpdater conversion works only in one direction. So you can't converter back to 0.22 from 0.40. Not quite sure yet how this OSyncUpdater thing might conflict with this multi- version GroupEnv? And i'm also not quite sure if it's really worth to put so much effort in supporting several APIs - at least so early ... But if someone wants to take care about this i'm not going to stop her/him ... At least i'm going to concentrate on a "simple" update-path for now ... As workaround people still can use --configdir from msynctool/osynctool to change the path from ~/.opensync to ~/.opensync0.22 or so ... 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: Chris F. <cd...@fo...> - 2009-09-26 03:49:37
|
Hi, I posted about this before, and was pointed to the following ticket: http://opensync.org/ticket/890 It appears that this ticket suggestion was not used. So there is the possibility of configurations conflicting between 0.22 and 0.4x. Fortunately, the following conflicts are resolved: - pkg-config: 0.22: opensync-1.0.pc 0.40: libopensync.pc (should be libopensync1.pc, but no biggie) - include directories: 0.22: /usr/include/opensync-1.0 0.40: /usr/include/libopensync1 - library names: 0.22: libopensync.so.0 and libosengine.so.0 0.40: libopensync.so.1 - plugin directory: 0.22: /usr/lib/opensync/plugins 0.40: /usr/lib/libopensync1/plugins Unfortunately: - HOME config 0.22: ~/.opensync 0.40: ~/.opensync I like the suggestion in #890. At least the 0.40 directory. Even a ~/.libopensync1 directory would be good... actually that's probably best. Since all configuration is supposed to be done through opensync anyway, the actual name of this directory shouldn't matter, and should, in my opinion, get renamed as the API and config formats change. If this were implemented, it would be possible to write applications that support both libraries at runtime, which I'm working on right now. As it is, I'll likely have to use non-standard configdirs for my app, which will separate it from all other opensync apps. This is ok too, I suppose, but not ideal. - Chris |
|
From: Daniel G. <go...@b1...> - 2009-09-25 11:24:13
|
On Thursday 24 September 2009 02:52:08 pm Douglas Lopes Pereira wrote: > Hi everyone, > > I've successfully installed opensync0.22 on my Debian box (running > 2.6.30 kernel) and also msynctool. I've also configured it to sync my > Nokia 5310 (using syncml and file plug-ins). > > When the sync finished, I noticed that some information was sent to my > phone (I saw it in the logs shown in the terminal). > > Browsing my contacts in the phone I saw that the name of the contacts > were duplicated. The field added has as identification the letters FN > (formal name?). > > Does anyone knows why were those fields added? I could imagine those got added during conversion from the xmlformat (which is internal used) to vcard 2.1 Unfortuantely in 0.22 there is no chance to solve this. Since 0.22 i not aware of capabilities of your mobile (e.g. does your mobile support the FN field?). The last years we concentrated to solve issues like this with handling capabilities information we get from the devices/applications. But this is only part of OpenSync 0.3x Hope that helps some how ... If you're a developer you might want to look into OpenSync 0.39 -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: Douglas L. P. <dou...@gm...> - 2009-09-25 11:07:39
|
Hi everyone, I've successfully installed opensync0.22 on my Debian box (running 2.6.30 kernel) and also msynctool. I've also configured it to sync my Nokia 5310 (using syncml and file plug-ins). When the sync finished, I noticed that some information was sent to my phone (I saw it in the logs shown in the terminal). Browsing my contacts in the phone I saw that the name of the contacts were duplicated. The field added has as identification the letters FN (formal name?). Does anyone knows why were those fields added? Thank you for your attention. Regards, Douglas |
|
From: Michael B. <mic...@cm...> - 2009-09-25 10:16:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 numlock wrote: > Just to keep any interested people informed: > > Daniel Gollub and I have been trying a few things concerning syncml with > google. We already know syncml-ds-tool works, but the opensync syncml plugin > doesn't work yet (even with latest trunk as of 2009-09-03). > > When I (and/or Daniel) can get a working syncml to/from google, I will post > some update here. But it's clear that the latest SVN version will be a > requirement in order to do that synchronization. This is not really correct. Google was tested with libsyncml 0.5.4. So the following things should work: libsyncml/tags/libsyncml-0.5.4 libsyncml/branches/libsyncml-0.5.x libsyncml/trunk The trunk is not compatible with the actual plugin code. The actual plugin bases on the 0.5.x API. Best regards Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq8mKAACgkQ2L0ZGCAwWqsHWQCdF6umrBxPPxmLaeTMqCZsZV22 XxUAn0FgXgLhSNJsY3U19BMuImaD1xiP =1z90 -----END PGP SIGNATURE----- |
|
From: Michael B. <mic...@cm...> - 2009-09-25 10:13:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Gollub wrote: > On Thursday 03 September 2009 01:16:27 pm Daniel Gollub wrote: >> >> https://libsyncml.opensync.org/wiki/tracing >> > > Hmmm the content of the wiki page is wrong... this is about OpenSync's tracing > not about libsyncml tracing ... I fixed the wiki page. Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq8l/YACgkQ2L0ZGCAwWqsiuACgqoitO91ZSM+pBDXqAAi+jGjo rvUAoM44TR6n1QQ+pd4Ob6N7QyY8u9zq =STEC -----END PGP SIGNATURE----- |
|
From: Michael B. <mic...@cm...> - 2009-09-25 09:07:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henrik, Henrik /KaarPoSoft wrote: > > Are there any progress / comments / plans on ticket 1078? > See also comments on the mailinglist regarding > "Remove pendingLimit from OSyncQueue". > > As far as I can see, this problem prevents any sync with SyncML devices, > as the SyncML protocol may have several changes in one message, > which I believe OpenSync cannot handle now... I am too far away from the actual OpenSync development. I am really happy if I can update the SyncML plugin to the actual OpenSync API until the end of October. So I'm sorry but I can only hope that Daniel or Bjoern find the time to fix the issue. Sorry Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq8iKcACgkQ2L0ZGCAwWqv1JQCfTkllksFtPxxY5F09awywLxg3 vk4AoJkwS98n/nDS5Frjf9Ahvm6wcrNt =QTle -----END PGP SIGNATURE----- |
90 messages has been excluded from this view by a project administrator.
