Re: Re: Bug: Current CVS in Playlist.pm

On Wed, Oct 24, 2001 at 04:24:43PM -0000, creeble-/[email protected] wrote:
> Excuse me for butting in here -- I'm just a guy w/a SliMP3 player 
> trying to stay up-to-date w/CVS -- but it would seem to me that the 
> easiest fix for this LWP problem is not to use it.  It's not quite 
> clear to me what it's being used for other than redirect detection, 
> and I'm sure "$reply =~ /Location:/i" should do the job there.
> 
> Or am I missing something?

LWP is the best way of handling the redirects.  "$reply =~
/Location:/i" won't always work, as a 302 isn't the only place that
string occurs.  So, though something like that may be the core of a
hand-written routine, you'd end up rewriting much of the functionality
inherent in LWP.

Hence, the whole point of libraries... portable, reusable code modules
built over time so you don't have to solve the same problems others
have already solved.

But, feel free to rewrite the redirect code in a robust manner to
eliminate LWP, and submit it.

We do quite a bit of URL string parsing as well, and at last count I
think we have 4 different code snippets each parsing URLs differently.
In the comments of the code I'm now working on, I suggest URI::URL as
a better solution, and may end up doing exactly that, cleaning up
several subroutines in Playlist.pm.

The fact that library use is an inherent good rather than something to
be avoided is the source of my concern about trying to include every
module we call in our own private @INC as part of the distribution.  I
only see us using more modules, not less, over time.  Eventually, the
bulk of the tarball's size will be given over to redistributing Perl
modules already available elsewhere, through appropriate mechanisms.
Honestly, I grok the fullness of the "ease of use" argument for
including them.  But let's not kid ourselves -- the SliMP3 is a
hardcore hacker geek's playground, and an end-user's nightmare.
Thinking that our private @INC makes a significant contribution to
ease-of-use is like thinking handing a pebble to a person who just
fell off a cliff will somehow mitigate the damage, because after all,
the pebble's part of good ol' terra firma.

If we really want to go for ease-of-use, we should just prepackage
ActiveState's Perl -- as a custom-tailored install -- as part of the
stable release, and have a bullet-proof install and config routine
that's entirely GUI-based.  For the UNIX users, the install script
should check the user's existing @INC and go grab any missing modules
 from CPAN rather than assuming we'll always distribute the appropriate
modules.  Our goal should be compatibility rather than forcing
explicit module versions.

Also, since you're tracking CVS, you should know that it's very 
unstable at this point...if you are worried about usability of CVS
code out-of-the-box, you should track the -stable feed, which is
the tarballed release code on the slimdevices.com website, or the
current stable rev on the sourceforge page.


-- 
Mark C. Langston
[email protected]
Systems & Network Admin
http://www.bitshift.org

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide!
http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/