PDA

View Full Version : repository XML, 7.4.0, & new vs. old hardware, a proposal



peterw
2009-09-22, 18:35
SBS 7.4.0 is nearly out and SB Radio will be shipping soon. SBS 7.4.0 makes it easier for users to find & install 3rd party plugins with the new checkbox that makes available virtually all 3rd-party plugins.

I expect a large number of new customers who only own a Squeezebox Radio will be considering what plugins to install. Many older plugins (most of mine, for instance), are designed more for the older players -- Boom, Classic, Transporter, etc. I think it would be useful for us as a community to adopt a convention for our repository XML "desc" elements to include information about which Squeezebox hardware a plugin works with. I suggest that the desc should include a list of supported hardware. For example, the description for my AllQuiet plugin would change from simply

"Silence all players simply by holding the Sleep button; all players will display the name of the player that asked for silence, in case you need help. Also provides a CLI command to silence/pause all players and display a custom message."

to

"Silence all players simply by holding the Sleep button; all players will display the name of the player that asked for silence, in case you need help. Also provides a CLI command to silence/pause all players and display a custom message. (Boom, Transporter, Classic, Squeezebox1, Slimp3, SoftSqueeze)"

Recommended player names: Boom, Transporter, Classic [meaning SB2/SB3/Classic], Squeezebox1, Slimp3, Receiver, Controller, Radio, Touch, SoftSqueeze, SqueezePlay [meaning SqueezePlay Desktop]. (Is "Squeezebox1" enough, or do we need to differentiate 1 vs 1G?)

It would be nicer if we extended the repo XML to add a "playerTarget" attribute so that customers might only see appropriate plugins (target references the server for plugins), but 1) that may be a lot to ask before 7.4.0 ships; 2) editing the desc elements as suggested might be good; 3) it might encourage folks to buy more hardware. :-)

What do you all think?

mherger
2009-09-22, 20:13
> I think it would be useful for us as a
> community to adopt a convention for our repository XML "desc" elements
> to include information about which Squeezebox hardware a plugin works
> with.

Very true.

> Recommended player names: Boom, Transporter, Classic [meaning
> SB2/SB3/Classic], Squeezebox1, Slimp3, Receiver, Controller, Radio,
> Touch, SoftSqueeze, SqueezePlay [meaning SqueezePlay Desktop]. (Is

Sounds reasonable - after all these are mostly the official product names.
Except that we're prepending them all with Squeezebox: Squeezebox Radio,
Squeezebox Classic etc.

> "Squeezebox1" enough, or do we need to differentiate 1 vs 1G?)

I'd say so, as if you eg. have something graphical, it would only run on
the G. SB1 more or less has the same capabilities as the SliMP3. But then
SliMP3 and SB1/G can be considered a very, very niche product nowadays.

> It would be nicer if we extended the repo XML to add a "playerTarget"
> attribute so that customers might only see appropriate plugins (target

We're already using this in the app store code on SN. As the internal
names (as reported by the players) are a bit different we're using the
following translation table:

my %playerTypes = (
'softsqueeze' => 'Softsqueeze',
'squeezebox2' => 'Squeezebox 2/3',
'transporter' => 'Transporter',
'softsqueeze3' => 'Softsqueeze Transporter',
'receiver' => 'Squeezebox Receiver',
'squeezeslave' => 'Squeezeslave',
'controller' => 'Squeezebox Controller',
'boom' => 'Squeezebox Boom',
'softboom' => 'Softsqueeze Boom',
'squeezeplay' => 'Squeezeplay',
'fab4' => 'Squeezebox Touch',
'baby' => 'Squeezebox Radio',
);

The right hand side is subject to changes...

> references the server for plugins), but 1) that may be a lot to ask
> before 7.4.0 ships;

No more changes but bug fixes to 7.4.x. Sure - descriptions may still be
changed :-)

This should be targeted at 7.5 or later.

erland
2009-09-22, 22:44
I expect a large number of new customers who only own a Squeezebox Radio will be considering what plugins to install. Many older plugins (most of mine, for instance), are designed more for the older players -- Boom, Classic, Transporter, etc. I think it would be useful for us as a community to adopt a convention for our repository XML "desc" elements to include information about which Squeezebox hardware a plugin works with. I suggest that the desc should include a list of supported hardware. For example, the description for my AllQuiet plugin would change from simply


When I started to update my repository XML files I realized that this isn't as simple as it looked like, some examples follows below. Based on this it feels like we really need to decide in which case a plugin should be marked as supported. If we don't, there is a risk the information only will be useful in the clear cases, for example screensaver plugins.


What does marking the "Controller" mean ? Does it mean that you have a user interface on the "Controller" or does it mean that the plugin can be useful for an owner of the "Controller" even though it doesn't have a user interface for it ?
- Custom Skip doesn't have a Controller user interface, but you can setup and activate the skipping filters through the web interface and then they are used when a "Controller" is used to control another devices.
- Since the Controller audio playback is beta and Custom Skip doesn't affect anything shown in the interface besides that tracks might suddenly disappear from the current playlist, I think it feels best to mark Custom Skip as NOT supported by the Controller but supported by the Receiver.


What does marking the "Receiver" mean ? Does it mean that your plugin has to to do something with the sound (since the Receiver doesn't have a user interface) or does it just mean that the plugin can do do something useful for an owner of a Receiver ?
- The Custom Skip plugin is a relevant question here. As mentioned above I think it feels best to mark it as supported by the Receiver.
- Another case is "Custom Browse" which doesn't do anything useful in the background but it can still be useful for an owner with a Receiver that controls it with iPeng. At the moment I don't think this enough to mark the "Receiver" as supported.
- A third case is "TrackStat" which both has background activities and a user interface. The user interface is obviously not shown on the "Reciever" but the background activities can still be useful for Receiver owners, especially if you combine the Receiver with a Controller or iPeng. In this case I think I could mark "Receiver" as supported due to the background activites.


How about plugins that neither have a user interface on Squeezeplay devices nor on Classic players but still is useful for both players ?
- On example is the Custom Scan plugin which only have a web interface, but it can be very useful on all player types together with Custom Browse which handles the user interface.
- Another example is the SQL Playlist plugin which also only have a web interface, but can be very useful on all player types together with Dynamic Playlist which handles the user interface.
- Database Query is third example which only have a web interface but potentially can be useful for owners of both Squeezeplay based devices and Classic players, not while playing music but when investigating problems with the setup or music library.
- At the moment it feels like all player types should be marked as supported on both Custom Scan and SQL Playlist and Database Query plugins.


I've can probably list more cases also but this should be enough to start the discussion.


Another situation is that I don't have all devices, so I've no idea if my plugin works on Squeezebox1 and Slimp3. I don't have a Transporter but it feels pretty safe to say that they work on a Transporter if they work on a Classic.

erland
2009-09-22, 22:50
It would be nicer if we extended the repo XML to add a "playerTarget" attribute so that customers might only see appropriate plugins (target references the server for plugins), but 1) that may be a lot to ask before 7.4.0 ships; 2) editing the desc elements as suggested might be good; 3) it might encourage folks to buy more hardware. :-)


At first I thought a new attribute made a lot of sense but I'm not sure anymore after I started to try to classify my own plugins. It would be a pity if I didn't mark a plugin as supported on a specfic player type and that results in that it can't be installed if someone finds some use for it.

It's works for applets since they are installed on the local Squeezebox device which makes it easier to say if they are supported or not, but it gets harder to mark support correctly for server side plugins.

I think appending the information to the description is a good start but it might be a good idea to wait with attribute support until plugins have been integrated with the "App Gallery".

mherger
2009-09-22, 23:20
> At first I thought a new attribute made a lot of sense but I'm not sure
> anymore after I started to try to classify my own plugins. It would be a
> pity if I didn't mark a plugin as supported on a specfic player type and
> that results in that it can't be installed if someone finds some use for
> it.

The only problem I see is with new products. But other than that? How
would you think might a user find a use for your plugin on a device you
didn't know it could be used with?

peterw
2009-09-23, 05:46
It is oversimplifying, I found that, too, but it still seems more helpful than saying nothing.

Another thought: perhaps write Receiver/Duet and Controller/Duet since I've seen posts from Duet customers suggesting they don't readily identify their gear with the Receiver and Controller product names.

Triode
2009-09-23, 12:25
I tend to think we should follow the desc route for the moment and gain some
understanding of how restrictive we can be.

If we added an extra entry in the repo xml, does this mean a player of this
type must be attached to the server when the plugin list is created? If so
the automatic detection of updates may become complex as we need to check at
the same time the relavent player type is attached.. Alternatively it could
be used to dynamically create the description element but no more - if so we
can probably handle with the desc element for the moment.

I do agree it would be good to encourage authors (especially for recommended
ones) to add to the description field if their plugin only works on selected
players.