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

The attitude that the SliMP3 is a hardcore hacker geek's playground (whether
that is true or not) is exactly the reason why every Linux GUI sucks the poo
 from the poo poo tree. It's as if no KDE or Gnome programmer knows how to
design a UI. By simply giving up on the normal end-user and deciding it's
not worth dealing with them by distributing the required modules - you're
cutting down your potential audience for the player. Including them, even if
we do end up with a big old half of CPAN distribution, isn't difficult to
do, and makes a hell of a difference (especially to Windows users, where
installing Perl modules isn't as easy as it is for *nix people).

I disagree that the system is an end-user nightmare too. A Windows user
(since they're the majority of users) can easily install ActivePerl, unzip a
file and run the server.pl within. That's the only three steps required to
get the server of this thing running. I'm sure we could even make the unit
configure itself by searching the network for the server.

Ease of use and install isn't an afterthought, it's something that has to be
in your mind every step along the way, even if it means you need to take a
few extra steps to get there.

Design and Program for the end-user, not the hardcode hacker geek that
happens to be using the system at the moment.


Richard Smith
[email protected]

- Free, REALLY customisable hosted messageboards
- http://www.chatbear.com/
- I wrote them, trust me, they're good... :)
- Plus, coming soon, http://www.theonewith.com/


> -----Original Message-----
> From: Mark C . Langston [mailto:[email protected]]
> Sent: 24 October 2001 17:59
> To: [email protected]
> Subject: Re: [slimp3-dev] 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
>
>
> 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/
>
>
>


------------------------ 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/