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

I agree, CPAN stuff has to be in our distribution.  Here are a few
possible arguments as to why we might *not* want to include them, and why
I disagree:

> The libraries are big and people might not need them

No, they're only a hundred K or so. I can see the server distribution
easily being a few megabytes in size - it will eventually include
documentation, graphics, sounds effects etc.

> It's other people's code. It doesn't belong in a source code
> distribution.

True, if we're talking about a source code tarball for developers which is
different from the distribution that users would download.  Being that
this is source code either way, I feel very strongly that users and
developers should use the same set of files, to minimize the
testing/packaging/install scripts headaches that we would have to go
through with each release.

> It might conflict with modules already on our systems

No, it won't. We're not trying to install anything in your /usr/lib/perl.
(This brings up the question of whether our lib/CPAN should come before or
after /usr/lib/perl/...)

> We don't really need all these modules

Let's not reinvent the wheel. Even if it's a smallish amount of code, we
should use the CPAN module if it does what we want.





On Wed, 24 Oct 2001, Richard Smith wrote:

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