On Sat, Apr 20, 2013 at 2:17 AM, till <klimpong@gmail.com> wrote:

On Saturday, April 20, 2013 at 1:35 AM, rodrigo wrote:

Is there any particular reason the default set of included (but not
activated) plugins has not been separated out from the main repository
into repositories of their own? I would even argue that skins, aside
from the default, should be separate repositories. My group manages our
installation with git and it would make my life a ton easier if this
were the case.

I don't remember when they were put back into the "master". They used to be
more separate.

Wrong. Plugins developed and maintained by the Roundcube developers

always have been part of the master git repository together with the

code code. The planned composer-based plugin repository is meant for

3rd party plugins. The main goal of that repository is to allow plugin

developers to publish their modules on a centralized platform and

allow Roundcube sysadmins to pull them into their local installations.

That isn't necessary for core plugins because they're already part of

the distribution package.

The plugins were in their own tree in SVN. Maybe that's what I meant.

We can easily spin them off with a git subtree split — also keeping the
history, etc.. But yeah, in its current state composer requires individual
repositories and so on. I guess this is more or less of question of handling
these externals.

I saw an answer to "[RCD] update.sh clobbering custom plugin configs in
main.inc.php?" earlier today, suggesting that a config file within the
plugin should be edited. Plugins are basically vendor code, wouldn't it
make more sense to make a plugin_name.inc.php within /config, and have a
plugin standard (in the form of a config grabber method) that grabs the
appropriate config file? This way, the plugin could be updated by
composer or git, and there'd be no worry about overwriting configs, or
editing vendor code. It'd encourage plugin writers to keep their config
separate from the roundcube config, because there'd be an easily
accessible function for it.

We already have that separation but not in the centralized /config

directory but in the individual plugin folders. And this basically

should survive an update via composer.

I'd also like that. I think up until now the configuration part hasn't seem
too much love and is very legacy. But if you have ideas, feel free to bounce
them around. :)

There's a general refactoring of the config system planned:

http://trac.roundcube.net/ticket/1487311

Please add your inputs and comments there.

~Thomas

_______________________________________________

Roundcube Development discussion mailing list

dev@lists.roundcube.net

http://lists.roundcube.net/mailman/listinfo/dev