PDA

View Full Version : Proposal for new preferences framework in 7.0 - looking for plugin author's feedback



Triode
2007-04-04, 14:55
I've been looking at a new preference framework for 7.0 which allows the server and each plugin to have its own preference namespace and provides a object based api for access preferences. The main advantage of this proposal is to avoid storing plugin preferences in the main server preference file which rapidly becomes full of legacy plugin information.

I'm looking for feedback on the api used for accessing preferences. I'll summarise the basics here - but please look at the demo plugin attached which illustrates the use of each of the features.

To define a namespace:

my $prefs = preferences('demo');

To set a global preference within this namespace either the get/set method can be used or an accessor method named the same as the preference can be used (this is dynamically created):

$prefs->set('pref1', 1);
or:
$prefs->pref1(1);

To get a global preference within this namespace:

my $val = $prefs->get('pref1');
or:
my $val2 = $prefs->pref1;

Similar object based methods are used to get client prefs for the namespace:

$prefs->client($client)->get('pref1')

Each preference can have a validator and an on change function associated with it. Additionally each name space has a version number associated with it to allow migration scripts to be run when first upgrading to a new version. These are demonstrated in the example plugin attached.

Each namespace is stored in a separate YAML file in a preferences directory. This will need to be located in the apropriate place for each archiecture/distro, but at present I've not looked at this in detail. The prefs for a given namespace will only be loaded when an object is created for that namesapce, so files for plugins which have been removed will remain in the prefs directory but will not be used.

The diff attached include my current implementation of the new scheme and migration of a couple of plugins and 3 server global prefs to the new scheme. It can be used with the plugin to test creation the new scheme.

Assuming feedback is positive I will look to migrate the 7.0 shipped plugins to the new scheme and then the server prefs themselves - but the key question for the moment is does the api look appropriate to plugin authors?

Adrian

erland
2007-04-04, 21:40
Assuming feedback is positive I will look to migrate the 7.0 shipped plugins to the new scheme and then the server prefs themselves - but the key question for the moment is does the api look appropriate to plugin authors?

This looks fine to me, it should be pretty easy to convert the plugins to use the new schema.

Will all the SlimServer preferences be in the 'server' namespace or will different parts of SlimServer use different namespaces ?

Is backward compatibility an issue ?
With this solution all the existing plugins must be changed to work at all since Slim::Utils::Prefs has been moved to Slim::Utils::OldPrefs. Would it be a good idea to keep the old prefs as Slim::Utils::Prefs and instead create a new Slim::Utils::NewPrefs or something for the new stuff ?

I'm not sure how the compatibility situation is with 7.0 and the new plugin architecture. If all plugins needs to be changed anyway because of the new plugin architecture the backward compatibility regarding the preferences shouldn't be an issue, but if some old plugins will work with the new plugin architecture unmodified it might be a good idea to also make the preferences solution backward compatible.

kdf
2007-04-04, 22:41
On 4-Apr-07, at 9:40 PM, erland wrote:
>
> Is backward compatibility an issue ?

not for 7.0

> I'm not sure how the compatibility situation is with 7.0 and the new
> plugin architecture.

The plugin API will require rewrites of all plugins, including a
slightly different directory structure and some packaging.
Older plugins will not even be loaded. Plugins for 7.0 will be added
via a download link, which grabs the package and extracts it to
the correct location. The wiki has more details.

http://wiki.slimdevices.com/index.cgi?SlimServer7Plugins

-kdf

Triode
2007-04-05, 10:51
> Will all the SlimServer preferences be in the 'server' namespace or
> will different parts of SlimServer use different namespaces ?

At present I was assuming all the server prefs would be in the one
namespace, but it would be equally easy to have a small number.

I need to look through the current prefs to see if there are any clear
groups which should be kept separate. Any views?

> Is backward compatibility an issue ?

Covered by kdf - changes are necessary for 7.0 so I had not planned this.
The only compatibility thing I've focused on is to provide an upwards
migration mechanism so the server and plugins can extract there old prefs
from the current prefs file.

JJZolx
2007-04-05, 11:58
At present I was assuming all the server prefs would be in the one
namespace, but it would be equally easy to have a small number.

I need to look through the current prefs to see if there are any clear
groups which should be kept separate. Any views?
Keep state separate. The main SlimServer prefs file shouldn't be written to constantly - only when a configuration option is saved by the user.

In doing the above, it might also be advantageous to separate player prefs from server prefs.

What I'm driving at is minimizing the need for users having to do a complete reinstall to overcome some state problem. A reinstall should never be necessary. If you can make it relatively easy to blow away server and player state then it would help a lot.

peterw
2007-04-05, 12:06
> Will all the SlimServer preferences be in the 'server' namespace or
> will different parts of SlimServer use different namespaces ?

At present I was assuming all the server prefs would be in the one
namespace, but it would be equally easy to have a small number.

I need to look through the current prefs to see if there are any clear
groups which should be kept separate. Any views?

I'd rather have one "flat" namespace for "server" preferences. I'd rather not have to remember not only what the preference name is, but what its namespace is -- easier to just have two preference objects, one for my plugin and one for the server.

Many plugins will need "read" access to the server preference namespace -- date and time formatting preferences are commonly accessed server preferences. Some like my SaverSwitcher plugin also need "write" access to server preferences. Therefore, please allow all plugins read and write access to any namespace they specify.

It would be nice to have an API for destroying an entire namespace (== deleting the .yaml file?) and a web interface that would expose that API to make it easier for users to "start afresh" if a plugin's preferences got messed up.

Thanks,

Peter

JJZolx
2007-04-05, 12:19
make it easier for users to "start afresh" if a plugin's preferences got messed up.
Absolutely, but why not make that either a required function of the new plugin architecture (you must have a "reset" function), or else automate it somehow in SlimServer, perhaps by requiring default values for all prefs. Again, also keeping the plugin's state separate from its prefs might make it easier to do a full reset without reinstalling.

peterw
2007-04-05, 12:33
It would be nice if developers were required to use names for their namespaces that were string tokens, and encouraged to use the same token as for getDisplayName(), as that would make it easier to create an interface for copying settings from one client to another. A web interface for copying settings (which I'm not suggesting needs to be a core server feature) might have three controls:
- a pulldown (single select) for the "source" of the settings
- a multi-select list of player "destinations" for the settings
- a multi-select list of plugins (namespaces)

An additional feature that would be required for copying would be APIs for enumerating preferences, e.g.

# get hash key => value pairs
%globalPrefs = $prefs->getPrefs();
%clientPrefs = $prefs->client($client)->getPrefs();

# just get prefence names in arrays
@globalPrefNames = $prefs->getPrefNames();
@clientPrefNamess = $prefs->client($client)->getPrefNames();

# list all namespace names (not just for $prefs object)
@allNamespaces = $prefs->listNamespaces();

Triode
2007-04-05, 12:43
> It would be nice if developers were required to use names for their
> namespaces that were string tokens, and encouraged to use the same
> token as for getDisplayName(), as that would make it easier to create
> an interface for copying settings from one client to another. A web
> interface for copying settings (which I'm not suggesting needs to be a
> core server feature) might have three controls:
> - a pulldown (single select) for the "source" of the settings
> - a multi-select list of player "destinations" for the settings
> - a multi-select list of plugins (namespaces)

I'll think about this - there's no restriction at present, I was probably
expecting authors to use a similar name to their logging name.

>
> An additional feature that would be required for copying would be APIs
> for enumerating preferences, e.g.
>
> # get hash key => value pairs
> %globalPrefs = $prefs->getPrefs();

$prefs->all and $prefs->client($client)->all should give this at present
(well hashref for this)

Sorry its not documented in the demo plugin.

> %clientPrefs = $prefs->client($client)->getPrefs();
>
> # just get prefence names in arrays
> @globalPrefNames = $prefs->getPrefNames();
> @clientPrefNamess = $prefs->client($client)->getPrefNames();

Can do this with keys on above?

>
> # list all namespace names (not just for $prefs object)
> @allNamespaces = $prefs->listNamespaces();
>

I'll add something for this.

kdf
2007-04-05, 13:02
Keep state separate. The main SlimServer prefs file shouldn't be written to constantly - only when a configuration option is saved by the user.


which states specifically?
immediately coming to mind:
volume, repeat, shuffle and (where supported) bass, treble, pitch.

-kdf

peterw
2007-04-05, 13:06
> %globalPrefs = $prefs->getPrefs();

$prefs->all and $prefs->client($client)->all should give this at present
(well hashref for this)

Sorry its not documented in the demo plugin.


That sounds great.




> @globalPrefNames = $prefs->getPrefNames();
> @clientPrefNamess = $prefs->client($client)->getPrefNames();

Can do this with keys on above?


Yes, absolutely.




>
> # list all namespace names (not just for $prefs object)
> @allNamespaces = $prefs->listNamespaces();
>

I'll add something for this.

Wonderful. Thank you!

JJZolx
2007-04-05, 13:07
which states specifically?
immediately coming to mind:
volume, repeat, shuffle and (where supported) bass, treble, pitch.

Any and all.

Triode
2007-04-05, 13:10
>> Keep state separate. The main SlimServer prefs file shouldn't be
>
> which states specifically?
> immediately coming to mind:
> volume, repeat, shuffle and (where supported) bass, treble, pitch.
>

Other than volume and power I don't think we change states frequently, but
take Jim's point. I propose we migrate across as one namespace and then
look to see if there is a benefit in extracting a small set of the states
out to a different namespace.

kdf
2007-04-05, 13:15
Quoting JJZolx <JJZolx.2ol2en1175803802 (AT) no-mx (DOT) forums.slimdevices.com>:

>
> kdf;192851 Wrote:
>> which states specifically?
>> immediately coming to mind:
>> volume, repeat, shuffle and (where supported) bass, treble, pitch.
>
> Any and all.

so you'd agree that list covers all of them?
any prefs missed that you'd consider states?

-kdf

JJZolx
2007-04-05, 14:55
so you'd agree that list covers all of them?
any prefs missed that you'd consider states?

No, it doesn't cover them all.

Are you trying to ask whether there are saved items that aren't clearly one or the other? Perhaps.

Title format is a preference
Current title format is a state

Most state information is client related. At the moment there are only a few server states that I see saved in the prefs file - a couple of lastchecked/lastupdated timestamps.

So maybe in addition to getting plugin data out of the prefs file, maybe moving client information at the same time would be good.

peterw
2007-04-05, 16:04
No, it doesn't cover them all.

Are you trying to ask whether there are saved items that aren't clearly one or the other? Perhaps.

Title format is a preference
Current title format is a state

Most state information is client related. At the moment there are only a few server states that I see saved in the prefs file - a couple of lastchecked/lastupdated timestamps.

So maybe in addition to getting plugin data out of the prefs file, maybe moving client information at the same time would be good.

"current title format" -- I don't follow your thinking. Current title is a state if the player is playing Internet Radio, but it's more like a preference if it's a playlist of local music, since players are expected to "remember" playlists.

You've suggested this "state" issue is about reliability:


What I'm driving at is minimizing the need for users having to do a complete reinstall to overcome some state problem. A reinstall should never be necessary. If you can make it relatively easy to blow away server and player state then it would help a lot.


Could you elaborate on that, give some concrete examples? I'm having trouble imagining what sorts of things you might discard at server shutdown that I would mind being discarded. I want my players to remember their volume, bass/treble/pitch, repeat, shuffle, and format string settings between server restarts.

As for the implied performance argument ("The main SlimServer prefs file shouldn't be written to constantly - only when a configuration option is saved by the user.") I think Triode has the right approach -- see if there's actually a benefit to not writing updates to the pref file. Personally I think that 1) my OS should do a good job caching filesystem access so that frequent "disk" access is mostly RAM activity and 2) most of these state changes are pretty infrequent (though volume changes typically involve stepping through 5-30 unique values).

Thanks,

Peter

JJZolx
2007-04-05, 16:33
"current title format" -- I don't follow your thinking. Current title is a state if the player is playing Internet Radio, but it's more like a preference if it's a playlist of local music, since players are expected to "remember" playlists.
Not the current title, the current title format. But yes, the playlist and the current track within the playlist are both parts of the player state. If they're lost, the user doesn't lose configuration settings that affect the way the player behaves.


You've suggested this "state" issue is about reliability:

Could you elaborate on that, give some concrete examples? I'm having trouble imagining what sorts of things you might discard at server shutdown that I would mind being discarded. I want my players to remember their volume, bass/treble/pitch, repeat, shuffle, and format string settings between server restarts.
I'm not suggesting throwing them away, or making them non-persisten; I just think this would make it easier to reset a server to its default state, without actually losing its configuration.


As for the implied performance argument ("The main SlimServer prefs file shouldn't be written to constantly - only when a configuration option is saved by the user.")

Not necessarily a performance argument. Some file(s)/database will need to be constantly written if client state is to be persistent across restarts. Maybe more of a philosophical argument.

erland
2007-04-05, 21:27
You've suggested this "state" issue is about reliability:

Could you elaborate on that, give some concrete examples? I'm having trouble imagining what sorts of things you might discard at server shutdown that I would mind being discarded. I want my players to remember their volume, bass/treble/pitch, repeat, shuffle, and format string settings between server restarts.
I'm not suggesting throwing them away, or making them non-persisten; I just think this would make it easier to reset a server to its default state, without actually losing its configuration.
If I would like to reset the server/player I think I would probably like to do this due to some configuration changes I have made. Due to this I don't really think discarding just the state would solve the situation, I would probably also like to discard parts of the configuration.

Separating plugin configuration in separate files is a good idea since it makes it easy to restore the plugin configuration to the default. The same thing for a player is also good, making it easy to return a single player to the default configuration. However, I can't really see the big benefit of doing the same for state.

One thing to think about regarding player preferences is plugin specific player preferences. In one way it would be good to have the preferences for a specific player in a single file, this would make it easier to copy preferences from one player to another. To make this work it would also mean that plugin specific client preferences should be stored in the player namespace and not in the plugin namespace. However, this would mean that there wasn't a good way of discarding plugin specific preferences for a player since they would be stored i the same file as standard player preferences.

Maybe it would be possible to create a sub directory for each player in the preferences directory ?
This way it would be easy to see which preferences that belongs to a single player and it would also be easy to discard the plugin specific player preferences.

Regarding the need to reset/restore server I would rather like to see some sort of backup/restore functionality instead of separating state in a separate file. With backup functionality the user can select to do a backup of the preferences before he makes any major changes, the the changes doesn't work he could easily do a restore of the previous backup. The optimal solution would be something like the "system restore" feature in Windows that does backups automatically, but that might be a bit too advanced.

By the way, is there a good reason why the preferences aren't stored in the MySQL database ?
The only preference I can see needs to be in a preference file is the database connection. If they were stored in the database that table could obviously not be cleared during rescan, but that shouldn't be a problem.

dean
2007-04-05, 22:48
On Apr 5, 2007, at 9:27 PM, erland wrote:
> JJZolx;192902 Wrote:
>>
>>>>> You've suggested this "state" issue is about reliability:
>>>
>>> Could you elaborate on that, give some concrete examples? I'm having
>>> trouble imagining what sorts of things you might discard at server
>>> shutdown that I would mind being discarded. I want my players to
>>> remember their volume, bass/treble/pitch, repeat, shuffle, and
>>> format
>>> string settings between server restarts.> >
>> I'm not suggesting throwing them away, or making them non-persisten;
>> I just think this would make it easier to reset a server to its
>> default state, without actually losing its configuration.
> If I would like to reset the server/player I think I would probably
> like to do this due to some configuration changes I have made. Due to
> this I don't really think discarding just the state would solve the
> situation, I would probably also like to discard parts of the
> configuration.
It's a very fuzzy line between configuration/settings/state. The
user changes something and that state should persist independent of
hidden things like processes starting and stopping, etc. Making a
distinction about this kind of state and that kind of configuration
just confuses things.

If what we're looking for is a way to reset to default settings for a
player or for the whole server, it makes sense to have button or menu
in the UI that says: "Reset player settings" or "Reset server
settings".

> Separating plugin configuration in separate files is a good idea since
> it makes it easy to restore the plugin configuration to the default.
Where it's stored doesn't matter (database, file, files, registry,
etc...) as long as the user has a means to control and reset it if
necessary. The fact that we developers know that they are in
particular doesn't help the user much.

Personally, as a developer, I like the idea of a single, human
readable file that can be inspected and if necessary, hand tweaked.
This approach has served us well for a long time, though the format
has changed over the years.

Triode
2007-04-06, 03:51
> One thing to think about regarding player preferences is plugin
> specific player preferences. In one way it would be good to have the
> preferences for a specific player in a single file, this would make it
> easier to copy preferences from one player to another. To make this
> work it would also mean that plugin specific client preferences should
> be stored in the player namespace and not in the plugin namespace.
> However, this would mean that there wasn't a good way of discarding
> plugin specific preferences for a player since they would be stored i
> the same file as standard player preferences.

I definately want to get plugin player preferences out of the main server
prefs as this was the prime motivator for this!

At present the code will only load the namespace if an object is created for
that namespace - which I think it the right thing to do - but it means that
a plugin must be loaded before its prefs file is loaded. So I think this
means cloning all player preferences complex - we would only clone the
preferences for plugins which are loaded at that point in time.

I think I would prefer that plugin authors make use of the initialisation &
migration mechanisms to set appropriate defaults for a new player. I'll
think about whether we can make it simpler to copy the prefs from an
existing player at this time.

> Regarding the need to reset/restore server I would rather like to see
> some sort of backup/restore functionality instead of separating state
> in a separate file. With backup functionality the user can select to do
> a backup of the preferences before he makes any major changes, the the
> changes doesn't work he could easily do a restore of the previous
> backup. The optimal solution would be something like the "system
> restore" feature in Windows that does backups automatically, but that
> might be a bit too advanced.

Hum - more to think about - I thought about simply renaming the existing
file to .bck. But with automatic saving on change its quite easy save twice
and loose this. Perhaps an archive and restore function is useful - will
consider this.

> By the way, is there a good reason why the preferences aren't stored in
> the MySQL database ?
> The only preference I can see needs to be in a preference file is the
> database connection. If they were stored in the database that table
> could obviously not be cleared during rescan, but that shouldn't be a
> problem.

My main reason was that at present everything in the Cache directory,
database included, is dyanmically built and so can re wiped and restored
from the source information. This is sometimes necessary if we don't bump
the schema versions properly and is something which has got people working
again in the past. Putting the prefs in there would mean we need to be far
more careful doing this! Although it could be done and I believe is done so
for SN, using YAML to get human readable prefs and handle serialising
complex datastructure seemed a valid thing to continue doing for SS. Its
only a couple of function calls, so could easily be replaced with a database
backend if we consider this appropriate later.

peterw
2007-04-06, 06:19
By the way, is there a good reason why the preferences aren't stored in the MySQL database ?
The only preference I can see needs to be in a preference file is the database connection. If they were stored in the database that table could obviously not be cleared during rescan, but that shouldn't be a problem.

I agree with most of the rest of your post, but, please don't store preferences in the database!

Both as a developer and a user, I've manually edited my prefs file. And I've long advocated using version control on the preferences file (http://wiki.slimdevices.com/index.cgi?SwitchingFromSubversionBackToGeneralRele aseOrDowngradingSlimServer). Moving to multiple YAML files offers a nice tradeoff -- easy cloning with 'cp', easy way to see what plugin owns what prefs, but more of a hassle to edit/version the preferences. Moving preferences to the database would make it harder to view and edit prefs by hand. I don't want to learn new SQL client apps just to tweak my Slim prefs.

-Peter

pippin
2008-01-25, 00:45
Can someone explain me how this works from an HTML perspective?
I'm trying to access client (player) settings and cannot get this to work.
Thx.

mherger
2008-01-25, 01:17
> Can someone explain me how this works from an HTML perspective?

Asking how _this_ works at this point is a bit... out of context :-). What exactly do you want to know?

Currently there's only one template for all skins. The skins only define the page header/footer. All the rest is built on the same templates.

> I'm trying to access client (player) settings and cannot get this to
> work.

Most important is the prefs variable available in TT. It's a hash with a value for every preference available on a given page. for players/basic.html this is one of "screensaver idlesaver offsaver screensavertimeout", eg. prefs.screensaver is the currently set screensaver.

namespace features the preferences namespace, by default 'server', in case of plugins something like 'plugin.musicinfoscr' (defined by the plugin author).

There's support for client side validation. The validate hash features a list of preferences which can be validated using the "pref validate" command:

postBody: Object.toJSON({
id: 1,
method: 'slim.request',
params: [
'',
[
'pref',
'validate',
namespace + ':' + myPref.name,
myPref.value
]
]
}),


--

Michael

pippin
2008-01-25, 01:58
>
Most important is the prefs variable available in TT. It's a hash with a value for every preference available on a given page. for players/basic.html this is one of "screensaver idlesaver offsaver screensavertimeout", eg. prefs.screensaver is the currently set screensaver.

OK, I should have been more precise: I want access from other pages than settings pages.
I know I can get that for server settings with
[% USE Prefs; Prefs.preferences('server').get('<item>') %]
But how does this work for player/client settings. I know the items I am looking for and I THOUGH I had understood the way they are organized in the preferences files and even what the perl stuff does, but there simply seems to be no sample code for how to access this from TT and I cannot get it to work.

mherger
2008-01-25, 02:10
> I know I can get that for server settings with
> [% USE Prefs; Prefs.preferences('server').get('<item>') %]
> But how does this work for player/client settings.

It doesn't. There's imho no way to get the player preferences. The above is defined in Plugin/TT/Prefs.pm, and there's no code for player preferences.

What you could do is using an AJAX only solution.

What prefs would you want to set?

--

Michael

pippin
2008-01-25, 02:25
> I know I can get that for server settings with
> [% USE Prefs; Prefs.preferences('server').get('<item>') %]
> But how does this work for player/client settings.

It doesn't. There's imho no way to get the player preferences. The above is defined in Plugin/TT/Prefs.pm, and there's no code for player preferences.

What you could do is using an AJAX only solution.

What prefs would you want to set?

I don't want to set any prefs, am already doing that through JSON/RPC, wanted to read prefs for initial page setup.

mherger
2008-01-25, 02:34
> I don't want to set any prefs, am already doing that through JSON/RPC,
> wanted to read prefs for initial page setup.

I guess I need to "Würme aus der Nase ziehen" :-). I can't help if you don't say what you want/need. What preferences do you need? Maybe they're already somewhere in the params hash?

--

Michael

pippin
2008-01-25, 02:56
> I don't want to set any prefs, am already doing that through JSON/RPC,
> wanted to read prefs for initial page setup.

I guess I need to "Würme aus der Nase ziehen" :-). I can't help if you don't say what you want/need. What preferences do you need? Maybe they're already somewhere in the params hash?


Ooops, sorry, After you said "doesn't work" I did see little chance...
There's quite a few, right now it's alarm settings, especially 'alarmfadeseconds'
Another issue would be plugins, especially trackstat, I would like to be able to get the "enabled" state of a plugin. But I don't know if that may even work with the mentioned above, didn't try yet.

mherger
2008-01-25, 03:16
> 'alarmfadeseconds'
> Another issue would be plugins, especially trackstat, I would like to
> be able to get the "enabled" state of a plugin. But I don't know if
> that may even work with the mentioned above, didn't try yet.

Na... these aren't the settings which are included in params by default :-).

But wait... you're lucky, I was wrong. What about:

[%
USE Prefs;
playerPrefs = Prefs.preferences('server').get("_client:$player");
playerPrefs.alarmfadeseconds;
%]

--

Michael

pippin
2008-01-25, 03:33
>
Na... these aren't the settings which are included in params by default :-).

But wait... you're lucky, I was wrong. What about:

[%
USE Prefs;
playerPrefs = Prefs.preferences('server').get("_client:$player");
playerPrefs.alarmfadeseconds;
%]


I THOUGHT I tried that... will try again. Wouldn't it be $playerid instead of $player?

mherger
2008-01-25, 03:44
> I THOUGHT I tried that... will try again. Wouldn't it be $playerid
> instead of $player?

No, player is the currently controlle player. playerid is only used in the settings pages, where you can edit a different player's settings.

--

Michael

pippin
2008-01-25, 04:01
found it: used 'client:$player' instead of "_client:$player". Working with TT AND JS just sucks...

pippin
2008-01-25, 06:28
BTW, if I change that setting (alarmfadeseconds) through JSON/RPC that change goes unnoticed by the Default Skin. The Preference File is updated and the change is persistent ("alarms" cmd as well as preferences.get return the changed value), and it also works but the Default Skin sticks to its value even when reloading the settings page or when opening a new instance, even in a different browser!!!

The other alarm settings are updated correctly.

mherger
2008-01-25, 07:17
> BTW, if I change that setting (alarmfadeseconds) through JSON/RPC that
> change goes unnoticed by the Default Skin.

http://bugs.slimdevices.com/show_bug.cgi?id=6774 - thanks!

--

Michael

Triode
2008-01-26, 04:48
> [%
> USE Prefs;
> playerPrefs = Prefs.preferences('server').get("_client:$player");
> playerPrefs.alarmfadeseconds;
> %]
>

Bear in mind that this is reaching into the internal hash used to store
preferences - it would be better to use the normal get/set methods to read
and definately for write...

I would like to propose adding something trivial to the Clients plugin to
get a client from the player id.

This would allow the following which would mean you can access everything by
methods.

[%
USE Prefs; USE Clients;
playerPrefs = Prefs.preferences('server').client(Clients.client( player));
playerPrefs.get('alarmfadeseconds');
%]

Addition is the following trivial new sub, so I recommend it for inclusion
in 7.0 if people agree:

sub client {
my $self = shift;
my $id = shift;
return Slim::Player::Client::getClient($id);
}

mherger
2008-01-26, 04:57
> Addition is the following trivial new sub, so I recommend it for
> inclusion in 7.0 if people agree:

Adrian - sounds good to me. Please file a bug and CC Dean. No change
without bug report before 7.0 is out. Thanks!

Michael

Triode
2008-01-26, 05:11
>> Addition is the following trivial new sub, so I recommend it for
>> inclusion in 7.0 if people agree:
>
> Adrian - sounds good to me. Please file a bug and CC Dean. No change
> without bug report before 7.0 is out. Thanks!

Bug raised - pending Dean.

Actually it would useful to know who uses the Clients TT plugin as the get
method would probably better be renamed all longer term and I suspect
new/load methods should be inherited.

Triode
2008-01-27, 14:45
Additional Clients method added to SC 7.0 so should be available in the next nightly - so please use to get to the real clientpref object rather than snooping its hash...

[%
USE Prefs; USE Clients;
playerPrefs = Prefs.preferences('server').client(Clients.client( player));
playerPrefs.get('alarmfadeseconds');
%]

mherger
2008-01-27, 23:55
> Additional Clients method added to SC 7.0 so should be available in the
> next nightly

Thanks!

--

Michael

pippin
2008-01-28, 02:31
Thanks, too :-)