Menu
▾
▴
opensync-devel
|
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-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 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: <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-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: 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 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: 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: 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: <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: 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: 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 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: 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: 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-29 23:48:13
|
On Sun, Sep 27, 2009 at 04:01:08AM -0400, Chris Frey wrote: > 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. The 3 main changes are now finished: - using XDG_CONFIG_HOME, defaulting to ~/.config/opensync/0.40 - the copy upgrade behaviour: when creating ~/.config/opensync/0.40 for the first time, it copies any existing ~/.opensync/group* directories into 0.40 - libopensync.pc was renamed to libopensync1.pc, with updates to cmake configs Version 0.22 does not recurse into the 0.40 directory, so even if 0.40 was inside ~/.opensync (which it isn't anymore) version 0.22 would not be bothered. I'm much happier now. :-) Thanks for the feedback folks. - Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Juha T. <Juh...@ik...> - 2009-09-30 08:36:29
|
On Wednesday 30 September 2009 02:47:36 Chris Frey wrote: > The 3 main changes are now finished: > - using XDG_CONFIG_HOME, defaulting to ~/.config/opensync/0.40 > - the copy upgrade behaviour: when creating ~/.config/opensync/0.40 > - libopensync.pc was renamed to libopensync1.pc, with updates to > I'm much happier now. :-) Thanks for the feedback folks. Me too! I wish all opensource desktop software would treat NFS and enterprise users like opensync does. :) Tuju -- Better to have one, and not need it, than to need one and not have it. |
Thanks for helping keep SourceForge clean.
X