why separate directories for SC plugins & 3rd party plugins

[Kiwi]

After some frustration with a non functional 3rd party plugin and searching the wiki and forum posts, I learned that there are two separate directories for plugins on a Windows system. The directory for plugins that are included in the SqueezeCenter software is typically;

C:\Program Files\SqueezeCenter\server\Slim\Plugin

The directory for 3rd party plugins is typically;

C:\Program Files\SqueezeCenter\server\Plugins

I am not a developer of plugins but I will say that as an end user trying to add a 3rd party plugin, it seems extraneous to have two directories and at the very least there needs to be better documentation of this structure for end users. I have edited the wiki but I wasn't sure how far to go without understanding the reasons or background for the two directories.

Can anyone educate me please?

[mherger]

> I am not a developer of plugins but I will say that as an end user
> trying to add a 3rd party plugin, it seems extraneous to have two
> directories

The user shouldn't need to care about Slim/Plugin. If you've found reference to it, then that reference was wrong.

Slim/Plugins is for stock plugins only. It will be overwritten during installation, deleted at will etc. Don't put anything in there.

Plugins is the place to put 3rd party plugins.

--

Michael

[kdf]

server\Slim\Plugin is for included plugins only. Slim/* may be wiped at
any time during SC upgrades.

server\Plugins is for third-party plugins. It may also be other
directories depending on the OS. The list of folders for your system is
listed in the server settings status page.

The reference to Slim/Plugin on that page is probably better off being
hidden.

-kdf

[hickinbottoms]

I understand that, but I've had a few queries over installation
locations for my plugins from other people that suggest it causes
confusion. In the medium term that might be solved with a plugin manager
that avoids users having to probe the intimate areas of SqueezeCenter
folders themselves, but it might also help in the shorter term if the
internal one was just called something different that didn't suggest it
was for plugins.

At the very least a text file called "NOT_FOR_USER_PLUGINS.txt" or
similar might be a clue if it was also present in there (oh, I was
forgetting localisation...).

Just an idea - it would be one less thing to get confused over or for
support people to have to check for.

Stuart

Michael Herger wrote:
>> I am not a developer of plugins but I will say that as an end user
>> trying to add a 3rd party plugin, it seems extraneous to have two
>> directories
>>
>
> The user shouldn't need to care about Slim/Plugin. If you've found reference to it, then that reference was wrong.
>
> Slim/Plugins is for stock plugins only. It will be overwritten during installation, deleted at will etc. Don't put anything in there.
>
> Plugins is the place to put 3rd party plugins.
>
>

[mherger]

> At the very least a text file called "NOT_FOR_USER_PLUGINS.txt" or
> similar might be a clue if it was also present in there (oh, I was
> forgetting localisation...).

Oh, would be great if you could come up with some text - my English isn't always the best. I'd definitely support this.

kdf suggested removing the Slim/Plugin path from the system information (which I've done in 7.3). This might already help a bit.

--

Michael

[ModelCitizen]

For me the problem is the term plugin. I understand plugins to consist of non-logitech supported functionality designed by third party developers.

Once any code becomes part of the Logitech-supported server software it ceases be a plugin.

It seems strange that stuff like Song Scanner, Sounds and Effects, Favorites & Command Line Interface are listed as plugins when they are obviously aren't. They are not optional and you can't remove them.

Maybe it's time the "plugin" definition was sorted out?

MC

[mherger]

> Once any code becomes part of the Logitech-supported server software it
> ceases be a plugin.

Plugin imho is a technical term, describing functionality which can be
plugged in or out. No matter where it's coming from.

> It seems strange that stuff like Song Scanner, Sounds and Effects,
> Favorites & Command Line Interface are listed as plugins when they are
> obviously aren't. They are not optional and you can't remove them.

Yeah, some used to be, but lost their status at some point.

> Maybe it's time the "plugin" definition was sorted out?

We'd rather have to sort out those plugins which aren't.

Michael

[Kiwi]

Thanks for the quick and informative responses. It seems that Michael has taken steps to only refer to the "user" plugin directory on the status tab for SC 7.3

The other suggestion to have a direction file in the system plugin directory is simple and easy, so I hope that is implemented also.

[moley6knipe]

Oh, would be great if you could come up with some text - my English isn't always the best

He, it's better than mine and I've lived here all my life!

[hickinbottoms]

What about "THIS DIRECTORY IS NOT FOR USER PLUGINS" (with whatever
combination of spaces or underscores you'd like)? I'll admit it's not
pretty, though.

I'd personally favour renaming it ("InternalPlugins", at least), but I
can imagine that would need a lot of Perl package renaming across the
software base so would be a pain. It's something I could try knocking up
a patch for if it would help (as an enhancement in Bugzilla, presumably).

Stuart


Michael Herger wrote:
>> At the very least a text file called "NOT_FOR_USER_PLUGINS.txt" or
>> similar might be a clue if it was also present in there (oh, I was
>> forgetting localisation...).
>>
>
> Oh, would be great if you could come up with some text - my English isn't always the best. I'd definitely support this.
>
> kdf suggested removing the Slim/Plugin path from the system information (which I've done in 7.3). This might already help a bit.
>
>