Plugin api brush-up

[mherger]

>> Was it the importer plugins?
>
> seems to be, yes.

Does it change with this patch?

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

[kdf]

Quoting Michael Herger <slim (AT) herger (DOT) net>:

> >> Was it the importer plugins?
> >
> > seems to be, yes.
>
> Does it change with this patch?

seems to be
at least, the strings aren't undef now. crashign now, so can't test if they
enable/disable properly. I have to rebuild a musicmagic library as well.

-kdf

[Steve Baumgarten]

dean blackketter wrote:

> The code I'm adding to ours is:
>
> if ($::VERSION gt '6.1')
>
> which should work as long as we don't change the version format.

Uh oh, another perl gotcha. That comparison breaks when the version goes
to 10 and above, as the "gt" operator does string comparison, not
numeric comparison.

Thus, while ("6.1" gt "6.0.2") IS true, ("10.0" gt "6.1") IS NOT true.

SBB






Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.

[Robert Moser]

Steve Baumgarten wrote:
> dean blackketter wrote:
>
>> The code I'm adding to ours is:
>>
>> if ($::VERSION gt '6.1')
>>
>> which should work as long as we don't change the version format.
>
>
> Uh oh, another perl gotcha. That comparison breaks when the version goes
> to 10 and above, as the "gt" operator does string comparison, not
> numeric comparison.
>
> Thus, while ("6.1" gt "6.0.2") IS true, ("10.0" gt "6.1") IS NOT true.
>
> SBB

Maybe we should have a versionStringToNum function in Slim::Utils::Misc
to convert the string $::VERSION (or a supplied string) to something
numeric.

sub versionStringToNum {
my $versionString = shift || $::VERSION;
my $versionNum = 0;
my $mult = 1;
for my $vpart (split(/\./,$versionString )) {
$versionNum += $vpart * $mult;
$mult /= 1000;
}
return $versionNum
}

This should (untested code) convert our 6.1.0 to 6.001000, 6.0.1 to
6.000001, and 10.0 to 10.000000. I used 1000 as the multiplier to match
the Perl versioning style. As long as we limit ourselves to 1000
versions/subversions, we should be ok.

[Marc Sherman]

Steve Baumgarten wrote:
> dean blackketter wrote:
>
>> The code I'm adding to ours is:
>>
>> if ($::VERSION gt '6.1')
>>
>> which should work as long as we don't change the version format.
>
>
> Uh oh, another perl gotcha. That comparison breaks when the version goes
> to 10 and above, as the "gt" operator does string comparison, not
> numeric comparison.
>
> Thus, while ("6.1" gt "6.0.2") IS true, ("10.0" gt "6.1") IS NOT true.

This also misses my original point, which is that you don't want a 6.1
plugin to try to launch with 7.0, when it comes out, because
historically, major version transitions have broken all the plugins in a
bad way.

- Marc

[dean]

On May 2, 2005, at 7:59 AM, Marc Sherman wrote:
> This also misses my original point, which is that you don't want a
> 6.1 plugin to try to launch with 7.0, when it comes out, because
> historically, major version transitions have broken all the plugins
> in a bad way.
These are the plugins that we ship with SlimServer and will
maintain. Can't predict when things will break, but when updating
the plugins for release we can adjust the requirements as necessary.

[mherger]

Ok, here's the latest plugin patch. It includes a patch for MusicMagic to
show how imho it could/should work:

- enabled() is a rather light check
- enabling the plugin will enable its functionality without the need to
activate it elsewhere again
- it only adds the additional settings page, but nothing under plugins and
server
- it does not yet inform the user whether the service is actually
available or not; this could be a 'changeMsg' or an intoductory text to
the plugin's own settings page

> at least, the strings aren't undef now. crashign now, so can't test if
> they enable/disable properly.

This patch is working (for me...) with MusicMagic installed on the same
machine.

> I have to rebuild a musicmagic library as well.

....which can take a while... after about 4h of fingerprinting it is still
< 10% of my collection. This could become a reason to replace my 1GHz
machine :-)

Please test and comment...

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

[mherger]

> Please test and comment...

....and I'm not only talking to kdf ;-)

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

[Marc Sherman]

dean blackketter wrote:
>
> These are the plugins that we ship with SlimServer and will maintain.
> Can't predict when things will break, but when updating the plugins for
> release we can adjust the requirements as necessary.

Right, but your code is often used as an example of how to write a
plugin by third party developers, so you should follow best practices
for third party plugins even in your in-house plugins.

If the plugin simply has a method that returns the required version, and
the actual comparison and verification logic was in the plugin loader
instead of the plugins themselves, that would simplify the many plugins
and provide consistent behaviour for all of them.

- Marc

[kdf]

Quoting Michael Herger <slim (AT) herger (DOT) net>:

>
> Please test and comment...

I have only been able to have a quick look. I'm seeing a lot of undef string
msgs that probably don't need to be there, since the relate to non 6.0+
compatible plugins. However, what used to be reported as such, no longer seems
to be.

I'm wondering if we're losing track of the (in fact) any design plan. I'm all
for improvements, but someone has to responsible for design decisions.
changing how something works shouldnt' be taken lightly, as a persons view of
'better' isn't always shared. Remember, this is a slim devices application.
while its a free license, it seems only fair to make sure everything is in line
with their goals. I've been feeling lately like I'm being asked to evaluate
design decisions, and I'm really not in a position to do so. I expect this was
not your intent, but is probably more the result of the fact that I seem to be
the only one discussing any of this stuff with you

-kdf