opensync-devel — The place to coordinate the development of OpenSync

Re: [Opensync-devel] *lib.la on plugins directory

[Eduardo P. H. <eha...@co...>]

On Fri, Apr 08, 2005 at 06:12:26PM +0200, Armin Bauer wrote:
<snip>
>=20
> ok. i really would like to keep them as close to the plugins as possible
> and not branch out into yet another directory. but renaming them to a
> more meaningfull name is ok for me. any suggestions? (i think auxfile is
> not more explicit than lib :)

What about calling them 'lib/foobar.so'?  :)

As you don't want to have another directory outside plugins, having
a directory inside the plugins directory would be a good choice, in
you opinion?

In the end, we are just replacing '*lib' by 'lib/*', but being
very clear about the files being special.

--=20
Eduardo

Re: [Opensync-devel] *lib.la on plugins directory

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

Eduardo Pereira Habkost wrote:
> On Fri, Apr 08, 2005 at 05:15:47PM +0200, Armin Bauer wrote:
> <snip>
>
>>!g_file_test(filename, G_FILE_TEST_IS_REGULAR) || g_file_test(filename,
>>G_FILE_TEST_IS_SYMLINK) || !g_pattern_match_simple("*.so", filename) ||
>>g_pattern_match_simple("*lib.so", filename)
>>
>>the lib.so test is there so we dont load files that end with *lib.so
>>which are library plugins (like the kdepim_sync.so and kdepim_lib.so files)
>
>
> This is exactly what I am arguing about: this implicit rule about file
> names ending with "lib". If the *lib.so files aren't plugins, why are
> they inside the plugins directory?
>
> If it was a more explicit name, like "*_auxfile.so", I wouldn't think it
> was too bad (althought I would still prefer to putting these auxiliary
> files on another directory, as they aren't plugins). But I think that
> "*lib" can be a bit confusing.
>

ok. i really would like to keep them as close to the plugins as possible
and not branch out into yet another directory. but renaming them to a
more meaningfull name is ok for me. any suggestions? (i think auxfile is
not more explicit than lib :)

Re: [Opensync-devel] *lib.la on plugins directory

[Eduardo P. H. <eha...@co...>]

On Fri, Apr 08, 2005 at 05:15:47PM +0200, Armin Bauer wrote:
<snip>
>=20
> !g_file_test(filename, G_FILE_TEST_IS_REGULAR) || g_file_test(filename,
> G_FILE_TEST_IS_SYMLINK) || !g_pattern_match_simple("*.so", filename) ||
> g_pattern_match_simple("*lib.so", filename)
>=20
> the lib.so test is there so we dont load files that end with *lib.so
> which are library plugins (like the kdepim_sync.so and kdepim_lib.so file=
s)

This is exactly what I am arguing about: this implicit rule about file
names ending with "lib". If the *lib.so files aren't plugins, why are
they inside the plugins directory?

If it was a more explicit name, like "*_auxfile.so", I wouldn't think it
was too bad (althought I would still prefer to putting these auxiliary
files on another directory, as they aren't plugins). But I think that
"*lib" can be a bit confusing.

--=20
Eduardo

Re: [Opensync-devel] *lib.la on plugins directory

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

Eduardo Pereira Habkost wrote:
> On Fri, Apr 08, 2005 at 04:10:10PM +0200, Armin Bauer wrote:
>
>>no. we wouldnt need it actually. its just to speed up the loading. the
>>code below just states to NOT load files ending with .la (which are
>>always installed from source). This is just a optimization to speed
>>things up.
>
>
> I am talking about the *lib.la-wont-load stuff, and not the *.la
> optimization.
>
> Actually, with the last change the '*lib.la' checking is redundant:
> *.la files will not be loaded, anyway.
>
>
>>The other reason to do this is to prevent people from creating special
>>files or other stuff in this directory that would then get loaded.
>
>
> Right, I agree with this. But, if we will load only the .so files,
> why not just check if the file ends with .so?
>

right. so this will do:

!g_file_test(filename, G_FILE_TEST_IS_REGULAR) || g_file_test(filename,
G_FILE_TEST_IS_SYMLINK) || !g_pattern_match_simple("*.so", filename) ||
g_pattern_match_simple("*lib.so", filename)

the lib.so test is there so we dont load files that end with *lib.so
which are library plugins (like the kdepim_sync.so and kdepim_lib.so files)

Re: [Opensync-devel] *lib.la on plugins directory

[Eduardo P. H. <eha...@co...>]

On Fri, Apr 08, 2005 at 04:10:10PM +0200, Armin Bauer wrote:
> no. we wouldnt need it actually. its just to speed up the loading. the
> code below just states to NOT load files ending with .la (which are
> always installed from source). This is just a optimization to speed
> things up.

I am talking about the *lib.la-wont-load stuff, and not the *.la
optimization.

Actually, with the last change the '*lib.la' checking is redundant:
*.la files will not be loaded, anyway.

>=20
> The other reason to do this is to prevent people from creating special
> files or other stuff in this directory that would then get loaded.

Right, I agree with this. But, if we will load only the .so files,
why not just check if the file ends with .so?

--=20
Eduardo

Re: [Opensync-devel] *lib.la on plugins directory

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

no. we wouldnt need it actually. its just to speed up the loading. the
code below just states to NOT load files ending with .la (which are
always installed from source). This is just a optimization to speed
things up.

The other reason to do this is to prevent people from creating special
files or other stuff in this directory that would then get loaded.

Eduardo Pereira Habkost wrote:
> On Fri, Apr 08, 2005 at 01:52:07PM +0200, svn...@op... wrote:
> <snip>
>
>>
>>-		if (!g_file_test(filename, G_FILE_TEST_IS_REGULAR) || g_file_test(filename, G_FILE_TEST_IS_SYMLINK) || g_pattern_match_simple("*lib.la", filename) || !g_pattern_match_simple("*.la", filename)) {
>>+		if (!g_file_test(filename, G_FILE_TEST_IS_REGULAR) || g_file_test(filename, G_FILE_TEST_IS_SYMLINK) || g_pattern_match_simple("*lib.la", filename) || g_pattern_match_simple("*.la", filename)) {
>> 			g_free(filename);
>> 			continue;
>> 		}
>
>
> Do we really need this *lib.la stuff? We are using the filename to
> separate files and create a new namespace. Isn't it what directories
> are supposed to do? If a *lib.la file isn't a plugin, so why is it on
> the plugins directory?
>
> It can be confusing: i.e. a developer write a plugin that has the
> main feature of using the 'foobarlib' to access the data used by other
> software using foobarlib, and calls his plugin: foobarlib. Then it won't
> load. (okay, bad example, but the main point is: if the module isn't a
> plugin, why is it inside the plugins directory?)
>
> Why not create a directory called 'pluginlib', 'modules', 'lib', or any
> other name, for these files?
>

[Opensync-devel] *lib.la on plugins directory

[Eduardo P. H. <eha...@co...>]

On Fri, Apr 08, 2005 at 01:52:07PM +0200, svn...@op... wrote:
<snip>
>  	=09
> -		if (!g_file_test(filename, G_FILE_TEST_IS_REGULAR) || g_file_test(file=
name, G_FILE_TEST_IS_SYMLINK) || g_pattern_match_simple("*lib.la", filename=
) || !g_pattern_match_simple("*.la", filename)) {
> +		if (!g_file_test(filename, G_FILE_TEST_IS_REGULAR) || g_file_test(file=
name, G_FILE_TEST_IS_SYMLINK) || g_pattern_match_simple("*lib.la", filename=
) || g_pattern_match_simple("*.la", filename)) {
>  			g_free(filename);
>  			continue;
>  		}

Do we really need this *lib.la stuff? We are using the filename to
separate files and create a new namespace. Isn't it what directories
are supposed to do? If a *lib.la file isn't a plugin, so why is it on
the plugins directory?

It can be confusing: i.e. a developer write a plugin that has the
main feature of using the 'foobarlib' to access the data used by other
software using foobarlib, and calls his plugin: foobarlib. Then it won't
load. (okay, bad example, but the main point is: if the module isn't a
plugin, why is it inside the plugins directory?)

Why not create a directory called 'pluginlib', 'modules', 'lib', or any
other name, for these files?

--=20
Eduardo

Re: [Opensync-devel] File releases

[Pierre O. <drz...@dr...>]

Armin Bauer wrote:
> Hi,
> 
> i was thinking about the way we release files. I used the sf.net file
> release system a bit and it seems to be quite complicated and slow.
> 
> The other option would be to attach the releases to this wiki page:
> http://www.opensync.org/wiki/download. So we would just attach the
> release to the page and add a link on the page.
> 
> So what do you think?
> 
> Armin

That would probably be better yes. The only advantage sf has is
automatic mirroring. But until bandwidth is a problem you should
probably stick to making your own releases on the project page.

Rgds
Pierre

[Opensync-devel] File releases

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

Hi,

i was thinking about the way we release files. I used the sf.net file
release system a bit and it seems to be quite complicated and slow.

The other option would be to attach the releases to this wiki page:
http://www.opensync.org/wiki/download. So we would just attach the
release to the page and add a link on the page.

So what do you think?

Armin

Re: [Opensync-devel] Plugins moved

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

Pierre Ossman wrote:
> Armin Bauer wrote:
>
>>Hi,
>>
>>i just moved the plugins. you can find the now under plugins/ (next to
>>trunk/). While this has the disadvantage of not being able to tag and
>>branch the plugins correctly, i think this is not a problem since we can
>>just create a /tags/plugins/ directory where we do this. Besides that it
>>should not happen often anyways)
>>
>>The example plugin is now located in /trunk/docs/example-plugin
>>
>>Armin
>
>
> The plugins have their own versions so is it necessary to tag and bundle
> them with the main opensync package? Their build structure also clearly
> seperates them since they expect opensync to be installed before you
> even run configure for each plugin.

Hmm both would possible. We could either always increment the plugin
version when we increment the opensync version so its clear which plugin
version should work. (But i think this is a lot of overhead since the
plugins rarely change once written)

The other possibility would be to make each tag a directory like this:

version-0.X/opensync
version-0.X/plugin1 etc

I think the neccessity for this disappears once we declare the plugin
interface stable since then the latest plugin HEAD version should always
work correctly

>
> Rgds
> Pierre
>

Re: [Opensync-devel] Plugins moved

[Pierre O. <drz...@dr...>]

Armin Bauer wrote:
> Hi,
> 
> i just moved the plugins. you can find the now under plugins/ (next to
> trunk/). While this has the disadvantage of not being able to tag and
> branch the plugins correctly, i think this is not a problem since we can
> just create a /tags/plugins/ directory where we do this. Besides that it
> should not happen often anyways)
> 
> The example plugin is now located in /trunk/docs/example-plugin
> 
> Armin

The plugins have their own versions so is it necessary to tag and bundle
them with the main opensync package? Their build structure also clearly
seperates them since they expect opensync to be installed before you
even run configure for each plugin.

Rgds
Pierre

[Opensync-devel] Plugins moved

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

Hi,

i just moved the plugins. you can find the now under plugins/ (next to
trunk/). While this has the disadvantage of not being able to tag and
branch the plugins correctly, i think this is not a problem since we can
just create a /tags/plugins/ directory where we do this. Besides that it
should not happen often anyways)

The example plugin is now located in /trunk/docs/example-plugin

Armin

Re: [Opensync-devel] New repository layout

[Eduardo P. H. <eha...@co...>]

On Tue, Mar 22, 2005 at 02:06:37PM +0100, Pierre Ossman wrote:
<snip>
>=20
> Since each plugin has its own build structure they should be in seperate
> directories in one form or another. But it might be cleaner to have them
> under a plugins directory first. I.e:
>=20
> opensync/branches/
> opensync/trunk/
> opensync/tags
> plugins/syncml-plugin/
> plugins/kdepim-plugin/ etc

Good point. Prepend "plugins/" to all plugin directories on the layouts
shown on my previous message. I think we don't need the "-plugin" suffix
if we are inside a "plugins/" directory, too.


--=20
Eduardo

Re: [Opensync-devel] New repository layout

[Eduardo P. H. <eha...@co...>]

On Tue, Mar 22, 2005 at 01:37:29PM +0100, Armin Bauer wrote:
> Hi,

Hi,

>=20
> we are planning to move the plugins out of the opensync dir. What should
> the new layout be?
>=20
> branches/
> trunk/ (opensync)
> tags/
> plugins/
>=20
> or
>=20
> opensync/branches/
> opensync/trunk/
> opensync/tags
> syncml-plugin/
> kdepim-plugin/ etc

My preferred layout has the problem of moving opensync to a new
subdirectory. It would be:

trunk/opensync/
trunk/sync-plugin/
trunk/kdepim-plugin/

But I agree with any layout, as long as they stay in a single repository
(i.e. allow cheap moves and copies between, without losing the history).

My order of preference is:

trunk/opensync/
trunk/sync-plugin/
trunk/kdepim-plugin/
branches/
tags/
(I like this because it doesn't break the trunk/branches/tags convention.
But it would move opensync to a subdirectory)

opensync/branches/
opensync/trunk/
opensync/tags
syncml-plugin/
kdepim-plugin/ etc
(I like this for the same reason as above. Altought it "breaks" the
trunk/branches/ tags convention on the first directory level, it keeps it
on the second directory level)
(I agree with this layout if, and only if, they stay on a single repository)


branches/
trunk/ (opensync)
tags/
plugins/
(This layout "breaks" the branches/trunk/tags convention, but I think it
can be justified if we don't want to move "opensync" to a subdirectory,
and if the layout above would imply on not having a single repository)

>=20
> or something else? What do you think?
>=20
> Armin



--=20
Eduardo

Re: [Opensync-devel] New repository layout

[Pierre O. <drz...@dr...>]

Armin Bauer wrote:
> Hi,
> 
> we are planning to move the plugins out of the opensync dir. What should
> the new layout be?
> 
> branches/
> trunk/ (opensync)
> tags/
> plugins/
> 
> or
> 
> opensync/branches/
> opensync/trunk/
> opensync/tags
> syncml-plugin/
> kdepim-plugin/ etc
> 
> or something else? What do you think?
> 
> Armin

Since each plugin has its own build structure they should be in seperate
directories in one form or another. But it might be cleaner to have them
under a plugins directory first. I.e:

opensync/branches/
opensync/trunk/
opensync/tags
plugins/syncml-plugin/
plugins/kdepim-plugin/ etc

The only big requirement I have is one 'configure' per tarball since it
makes rpm-building a bit more sane =)

Rgds
Pierre

[Opensync-devel] New repository layout

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

Hi,

we are planning to move the plugins out of the opensync dir. What should
the new layout be?

branches/
trunk/ (opensync)
tags/
plugins/

or

opensync/branches/
opensync/trunk/
opensync/tags
syncml-plugin/
kdepim-plugin/ etc

or something else? What do you think?

Armin