PDA

View Full Version : Update Software Roadmap



Dan Sully
2005-08-08, 14:27
I've just updated the Software Roadmap with our goals / investigations for
the next few releases of SlimServer. Comments welcome.

http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap

-D
--
<phone> i am a sausage fan

MrC
2005-08-08, 15:43
Very nice to see this - thanks!

JJZolx
2005-08-08, 15:43
I've just updated the Software Roadmap with our goals / investigations for
the next few releases of SlimServer. Comments welcome.
Very nice. With regard to:

> Move to MySQL as backend db - fix concurency issues with
> DBD::SQLite, split scanning into separate thread/process

Move to MySQL, as in officially supporting MySQL, or as in making MySQL the default database for new installs?

Dan Sully
2005-08-08, 15:48
* JJZolx shaped the electrons to say...

>> Move to MySQL as backend db - fix concurency issues with
>> DBD::SQLite, split scanning into separate thread/process
>
>Move to MySQL, as in officially supporting MySQL, or as in making MySQL
>the default database for new installs?

Making it the default database for new installs.

-D
--
"Hey, careful, man, there's a beverage here!"

Ian Whalley
2005-08-08, 16:41
>I've just updated the Software Roadmap with our goals /
>investigations for the next few releases of SlimServer.
>Comments welcome.
>http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap

At the risk of being totally self-centred, for which I
apologise... does bug 775 (not explicitly mentioned)
fall into any of the larger categories? I couldn't work out
which it might be.

Thanks;

inw

--
Ian Whalley <first name> @ <last name> . org

tygar
2005-08-08, 17:08
Thanks so much for the updated roadmap. It really is wonderful to see what is in the future for the SlimServer.

I thought I'd add my two cents to the discussion -- as an end user. I realize it is fairly presumptious to do this on a developer's forum, but with Dan Sully's invitation, it is fairly hard to resist.

Here are some directions I'd like to see Slim Server take:

(1) Better support for podcasts. The current podcast plug-in is great, but it would be even better if it were straightforward to add podcasts to the SqueezeBox listening experience (since I usually don't listen to top-50 PodcastAlley podcasts, I'm hoping for a more comprehensive solution.)

(2) Support for WMA and RealAudio streaming Internet Radio stations. Of course, some of this is already provided by AlienBBC, but it seems that most people have lots of trouble with AlienBBC -- they either can't get it working (I'm convinced the MacOS version has a serious bug) or it produces bad audio quickly. It would be a major plus for the Squeezebox if non-MP3 Internet Radio were fully integrated into the SlimServer and/or Squeezebox and/or SqueezeNetwork.

I'm very impressed by the quality and features added to recent versions of SlimServer. This product keeps on getting better, and the integration with RadioIO, Live365, and SqueezeNetwork is great!

kdf
2005-08-08, 19:48
On 8-Aug-05, at 5:08 PM, tygar wrote:
>
> (1) Better support for podcasts. The current podcast plug-in is great,
> but it would be even better if it were straightforward to add podcasts
> to the SqueezeBox listening experience (since I usually don't listen to
> top-50 PodcastAlley podcasts, I'm hoping for a more comprehensive
> solution.)
>
If you are an iTunes user, then any podcasts you download via iTunes
will be made available in the browse music options.

-kdf

Peter Watkins
2005-08-08, 20:08
On Mon, Aug 08, 2005 at 03:48:20PM -0700, Dan Sully wrote:
> * JJZolx shaped the electrons to say...

> >Move to MySQL, as in officially supporting MySQL, or as in making MySQL
> >the default database for new installs?
>
> Making it the default database for new installs.

Dan, thanks for the pointer. Quick thoughts:

1) Bundling Apps

This, and 7.0's "Re-architect event/threading/forking model. Investigate
using mod_perl/apache to handle all the web based interaction" sound risky.
Given that Windows is a target platform, you'll have to bundle compiled
MySQL and Apache Httpd binaries with SlimServer, and that means Slim will
need to release minor patches whenever MySQL or Apache have new releases
to fix security problems or significant bugs.

2) Web Security

The CSRF protection in SlimServer is predicated on Slim's HTTP interface
not supporting POST requests. If Slim moves toward a more "traditional"
Apache + mod_perl/CGI.pm model, the threat model will change and different
countermeasures may be required.

-Peter

Dan Sully
2005-08-08, 20:16
* Peter Watkins shaped the electrons to say...

>Dan, thanks for the pointer. Quick thoughts:
>
>1) Bundling Apps
>
>This, and 7.0's "Re-architect event/threading/forking model. Investigate
>using mod_perl/apache to handle all the web based interaction" sound risky.
>Given that Windows is a target platform, you'll have to bundle compiled
>MySQL and Apache Httpd binaries with SlimServer, and that means Slim will
>need to release minor patches whenever MySQL or Apache have new releases
>to fix security problems or significant bugs.

Yes - I'm aware of this. However, I believe the benefits outweigh the costs.

We're really getting hammered by supporting *everything* - as a company, we
need to officially support 3 platforms:

Windows
OSX
Linux (pick one)

For everyone else - there will be instructions on how to get up and running.

Specialized platforms such as the Linkstation will have their own builds as well.

>2) Web Security
>
>The CSRF protection in SlimServer is predicated on Slim's HTTP interface
>not supporting POST requests. If Slim moves toward a more "traditional"
>Apache + mod_perl/CGI.pm model, the threat model will change and different
>countermeasures may be required.

That is correct - however, more mainstream approaches can be taken when using
a standard interface. Also, I believe we support POST now with Jacob's
XML-RPC change.

-D
--
There is no emergency. Nothing to see here. Move along.

JJZolx
2005-08-08, 20:26
I hadn't realized what the 7.0 architecture changes meant. Are you saying that SlimServer will lose its internal HTTP server and move to operating with Apache?

I see the need for the bundled MySQL and Apache servers on Windows, if only to ease installation for most Windows users, but will the SlimServer of the future also operate with non-bundled installations of each of those servers on the Windows platform?

What do you expect to be the net results in the overall memory footprint of SlimServer + MySQL + Apache?

Is the current support only for GET by design or simply a limitation of the built-in HTTP server? I'd been wondering why everything was done with GETs.

Dan Sully
2005-08-08, 20:44
* JJZolx shaped the electrons to say...

>I hadn't realized what the 7.0 architecture changes meant. Are you
>saying that SlimServer will lose its internal HTTP server and move to
>operating with Apache?

Yes. This way Apache can handle all of the issues that we've had trouble with
- including forking, caching, etc.

Please keep in mind that this is something we want to investigate, and
initially looks promising. We haven't gone any further than that. Subject to
change, etc. Where's your rewrite in Haskell, Jim? ;)

>I see the need for the bundled MySQL and Apache servers on Windows, if
>only to ease installation for most Windows users, but will the
>SlimServer of the future also operate with non-bundled installations of
>each of those server?

I don't quite understand the question here.. Are you asking if you have your
own version of Apache, etc will it run? The answer is "I'm not sure yet."

If we want to support the SliMP3, there is a patch for Apache to handle UDP
connections, which has not been integrated into the mainline Apache tree yet.

>What do you expect to be the net results in the overall memory
>footprint of SlimServer + MySQL + Apache?

I can't say right now, as I don't know.

>Is the current support only for GET by design or simply a limitation of
>the built-in HTTP server? I'd been wondering why everything was done
>with GETs.

It's a limitation of the original server from way back when.. there's never
been any real need for supporting POST. Though Jacob just added that support
for his XML-RPC plugin.

-D
--
<nil> It sucks to discover that you are the foremost authority on some set of things when you've got a problem.

dean
2005-08-08, 21:24
On Aug 8, 2005, at 8:44 PM, Dan Sully wrote:
> Please keep in mind that this is something we want to investigate, and
> initially looks promising. We haven't gone any further than that.
> Subject to
> change, etc. Where's your rewrite in Haskell, Jim? ;)
Indeed. There's a lot to learn and do before we'd make such a
dramatic change to the architecture.

The point of the software roadmap is to open some discussion about
both the long-term and short-term plans for SlimServer to the community.

I'd like to think about this move in stages. Since we've identified
a serious issue with SQLite in that we can't support multi-process
access to the database, moving to MySQL seems like an important first
step. This should also let us fork off a separate scanning process,
which could have a substantial visible improvement to UI performance
during scans.

> It's a limitation of the original server from way back when..
> there's never
> been any real need for supporting POST. Though Jacob just added
> that support
> for his XML-RPC plugin.
If we have POST now, let's get the setup pages to use it so we can
avoid the CSRF warnings that keep cropping up.

-dean

Dan Sully
2005-08-08, 22:11
* Robert Moser shaped the electrons to say...

>For this:
>Deploy our own Perl on OSX to support unicode on 10.1, 10.2
>
>It might be worthwhile to check out PAR (http://par.perl.org/index.cgi) for this.

Unfortunately, PAR doesn't actually bundle perl itself.

There's also a support issue.

ActiveState now has an OSX build.

-D
--
<dr.pox> does whistling in the dark make me go blind faster?

Grotus
2005-08-08, 22:14
For this:
Deploy our own Perl on OSX to support unicode on 10.1, 10.2

It might be worthwhile to check out PAR (http://par.perl.org/index.cgi)
for this.

oreillymj
2005-08-09, 00:54
Just some comments on the roadmap. This is my own personal wish-list, so I'm not expecting every/anyone to agree.

1)Fix library scanning so that I can keep just the tracks I play daily in my library, but still have tracks I rarely want to play acessible using playlists.
I like to keep film soundtracks/x-mas music/classical outside my library, so they aren't played when I put my library on shuffled playback.

2)Fix crossfading so that it works on mp3 files. My idea of crossfading is the Winamp plugin available here http://www.sqrsoft.com.ar/en/index.html. Nobody else seems to have longged a bug about this, but x-fading does nothing for me.

3)Split code into 3 threads to keep the app more responsive. 1 thread for Db activity, 1 for UI & 1 for playback.

4) Enable native WMA playback. It doesn't have to support DRM, although M$ will probably not license the codec without DRM in place. There are plenty of radio stations using this format which I could listen to even without the DRM bit. I don't care about REAL as that format and associated software sucks big-time.

5) Personally I use Winamp to create playlists, but there's a really cool LGPL Javascript library here http://cross-browser.com/ than could add a log of drag-ndrop features to the UI. I'd have a crack at this myself if I understood the UI rendering code. Is it PHP?

6)Fix the bug whereby, if you pause a track within about the last 30secs.- 1 minute of the end of the track and the resume playback, the player will pause again at the end of the track. You then need to press ffwd to play the next track in the playlist.

7)DRM support will probably be a must-have before long, but at the moment this is low priority. I have enough legal music to keep me amused for a long time and would rather have a physical CD, than buy a DRM'd track that I can't moved off my PC.

Peter Watkins
2005-08-09, 07:38
On Mon, Aug 08, 2005 at 09:24:50PM -0700, dean blackketter wrote:
>
> On Aug 8, 2005, at 8:44 PM, Dan Sully wrote:

> > It's a limitation of the original server from way back when..
> > there's never
> > been any real need for supporting POST. Though Jacob just added
> > that support
> > for his XML-RPC plugin.
> If we have POST now, let's get the setup pages to use it so we can
> avoid the CSRF warnings that keep cropping up.

Switching to POST won't stop CSRF attacks. It's only marginally more
difficult for an attacker to craft a POST attack than a GET attack.

Plus, you want to allow people to kep using their bookmarks for
issuing commands to the server (as documented), right? Supporting
simple bookmarks means suporting simple GET requests for setup pages.

I think you'd be better off making sure the setup (and other "dangerous"
pages) continued to use only GET requests, as then at least the
current CRSF protection scheme would be valid.

>From a security standpoint, the simplicity of the Slim HTTP server is
a very good thing -- it makes it easier to understand and protect against
threats when there are fewer input vectors.

-Peter

dean
2005-08-09, 08:10
On Aug 9, 2005, at 7:38 AM, Peter Watkins wrote:
> Switching to POST won't stop CSRF attacks. It's only marginally more
> difficult for an attacker to craft a POST attack than a GET attack.
Ok, I stand corrected, that makes sense.

> Plus, you want to allow people to kep using their bookmarks for
> issuing commands to the server (as documented), right? Supporting
> simple bookmarks means suporting simple GET requests for setup pages.
I didn't mean that we'd pull out GET support, rather if it was secure
against those attacks, use POST when possible, GET when necessary.

> I think you'd be better off making sure the setup (and other
> "dangerous"
> pages) continued to use only GET requests, as then at least the
> current CRSF protection scheme would be valid.
If POST is supported now, then it should be fortified against CRSF as
well.

fuzzyT
2005-08-09, 13:03
Dan Sully wrote:
> I've just updated the Software Roadmap with our goals / investigations for
> the next few releases of SlimServer. Comments welcome.

A few thoughts:

I'm very glad to see the mySQL and Apache/modPerl items appearing on the
list.

Architecting SS similarly to a classic web application should relieve
much of the pain around performance and scaling, as well as basic issues
like HTTP conformance.

Don't get me wrong, the SS team has done a fantastic job to date. It's
just some layers of the stack have been solved and it can be better,
faster and cheaper to leverage what's out there.

And this change won't come without some adaptation.

As noted, there would be service dependencies and 3rd party updates to
track and distribute. But that's probably OK, a problem that has been
solved many times before.

And, yes, exposing the a full Apache installation can have it's dangers.
But, it's also possible to configure away much of the complexity and
expose only what necessary, use it's built-in security, aggressively
filter user inputs, allow only local connections, and otherwise set
relatively safe defaults. And the benefits of having a stable, proven,
performant, and secure HTTP implemenation are huge.

Similar types of gains can be had from modPerl (session management, db
connection pooling, etc.) and mySQL (more compliant SQL engine,
multiuser performance, etc.)

I can also see where there may be developer participation gains. An
Apache/modPerl/mySQL platform, with proper MVC division of labor, may
prove to be a lot more approachable for potential developers.

--rt

sben
2005-08-09, 13:10
ron thigpen wrote:
> Dan Sully wrote:
>
>> I've just updated the Software Roadmap with our goals / investigations
>> for the next few releases of SlimServer. Comments welcome.
>
> And, yes, exposing the a full Apache installation can have it's dangers.

Speaking of full Apache installations, has LightTPD
(http://www.lighttpd.net/) been considered?

-- S. Ben Melhuish

alex wetmore
2005-08-09, 13:26
On Tue, 9 Aug 2005, S. Ben Melhuish wrote:
> Speaking of full Apache installations, has LightTPD
> (http://www.lighttpd.net/) been considered?

This hardly seems to be cross platform, which seems like a requirement
for Slimserver.

alex

Hakan Tandogan
2005-08-09, 14:25
ron thigpen wrote:
> Dan Sully wrote:
>
>> I've just updated the Software Roadmap with our goals / investigations
>> for
>> the next few releases of SlimServer. Comments welcome.
>
>
> A few thoughts:
>
> I'm very glad to see the mySQL and Apache/modPerl items appearing on the
> list.
>
> [ ... ]
>
> As noted, there would be service dependencies and 3rd party updates to
> track and distribute. But that's probably OK, a problem that has been
> solved many times before.

Speaking of which, it would be really nice if the SlimServer could run
with a stock apache installation, just like it is with MySQL.

The good people at slimdevices solved the problem of system-wide
installed perl modules with quite a bit of @INC trickery, but handling
major patches to the apache core sounds like a little bit too much for
most of the casual users (remember those who could / would not install a
new perl version on their linux servers)


Regards,
Hakan


--
Simpler is better. But try telling that to any young fool who hasn't
even fought in the clone wars...

JJZolx
2005-08-09, 15:41
>I see the need for the bundled MySQL and Apache servers on Windows, if
>only to ease installation for most Windows users, but will the
>SlimServer of the future also operate with non-bundled installations of
>each of those server?

I don't quite understand the question here.. Are you asking if you have your
own version of Apache, etc will it run? The answer is "I'm not sure yet."
Yes, that's what I mean. I'd prefer the option, even on a Windows system, to be able to run with standard versions of Apache and MySQL. I already have both running on my XP system on which SlimServer runs and I imagine it's common with users running Linux servers.

Dan Sully
2005-08-09, 15:46
* JJZolx shaped the electrons to say...

>> I don't quite understand the question here.. Are you asking if you have
>> your
>> own version of Apache, etc will it run? The answer is "I'm not sure
>> yet."
>
>Yes, that's what I mean. I'd prefer the option, even on a Windows
>system, to be able to run with standard versions of Apache and MySQL.
>I already have both running on my XP system on which SlimServer runs
>and I imagine it's common with users running Linux servers.

Your own MySQL: Almost definitely.

Your own Apache: Unclear. If we want to support SliMP3 users, we need a patch
to Apache to support UDP connections.

-D
--
Do not panic, do not panic! We are trained professionals!
Now, stay calm. We are going around the leaf.

Philip Meyer
2005-08-09, 16:28
Hi Dan Sully <dan (AT) slimdevices (DOT) com>,

Just curious - why the jump from 6.2 to 6.5? Are 6.3 and 6.4 expected to be minor patches to 6.2 for issues that crop up in that release, or are some of the 6.2 bits going to be broken out into 6.3 and 6.4?

Phil

Dan Sully
2005-08-09, 16:30
* Philip Meyer shaped the electrons to say...

> Just curious - why the jump from 6.2 to 6.5? Are 6.3 and 6.4 expected to
> be minor patches to 6.2 for issues that crop up in that release, or are
> some of the 6.2 bits going to be broken out into 6.3 and 6.4?

The jump to using MySQL is why I picked 6.5

-D
--
Minds are like parachutes... they work best when open.

Philip Meyer
2005-08-09, 16:41
>The jump to using MySQL is why I picked 6.5
>
Okay.

BTW, I notice that your replies always have a title "[Developers] Re: ....", whereas most other replies are "Re: [Developers] ...". Is this an affect/difference due to posting from forums, and if so can it be changed to be consistent with email posts?

I only recently noticed this because I switched my email client to "allow threading by subject", whereas normally it will thread by message id's. I'll probably change back, and it's not a big deal. Don't want to start another forum/mail flame war :-)

Phil

Dan Sully
2005-08-09, 16:43
* Philip Meyer shaped the electrons to say...

> BTW, I notice that your replies always have a title "[Developers] Re: ...",
> whereas most other replies are "Re: [Developers] ...". Is this an
> affect/difference due to posting from forums, and if so can it be changed
> to be consistent with email posts?

My incoming filter (procmail) strips of the [Developers] tag, as it's rather
useless when one filters into folders. So the reply becomes slightly munged.

-D
--
You know, for kids.

John A. Tamplin
2005-08-09, 17:19
On Tue, 9 Aug 2005, Dan Sully wrote:

> Your own Apache: Unclear. If we want to support SliMP3 users, we need a patch
> to Apache to support UDP connections.

Maybe I don't understand the proposed architecture -- I would assume that
an Apache-based Slimserver would run the web interface in Apache, and
other processes would be responsible for player streaming, database
scanning, etc. In that scenario, why would Apache need UDP support?

--
John A. Tamplin jat (AT) jaet (DOT) org
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723

Dan Sully
2005-08-09, 17:22
* John A. Tamplin shaped the electrons to say...

>>Your own Apache: Unclear. If we want to support SliMP3 users, we need a patch
>>to Apache to support UDP connections.
>
>Maybe I don't understand the proposed architecture -- I would assume that
>an Apache-based Slimserver would run the web interface in Apache, and
>other processes would be responsible for player streaming, database
>scanning, etc. In that scenario, why would Apache need UDP support?

My initial thoughts (and some from Robin) - and I'm not sure if this is
feasable or not yet - is to use Apache as the handler for SlimProto &
Streaming as well. Use it's infrastructure & socket handling, etc.

Everyone always complains 'separate out streaming into a different process!'
- well, it's not that easy. Streaming is actually done over port 9000, ie:
it's handled by the internal web server. Having Apache handle that is a no-brainer.

-D
--
<weezyl> Oh, I cook bacon naked all the time. You just have to keep the heat on med-low.

Peter Watkins
2005-08-09, 17:28
On Tue, Aug 09, 2005 at 10:49:09AM -0400, John A. Tamplin wrote:
> On Tue, 9 Aug 2005, Peter Watkins wrote:
>
> > From a security standpoint, the simplicity of the Slim HTTP server is
> > a very good thing -- it makes it easier to understand and protect against
> > threats when there are fewer input vectors.
>
> True, but there are other benefits to switching -- a proven
> high-performance model with many other people working on new features, bug
> fixes, cross-platform portability, and performance enhancements. I

I was nodding my head up til "performance enhancements". I wouldn't
expect that, not necessarily. But neither performance concerns nor the
notion that it's easier to secure a smaller, simpler app should be
construed as arguments against using Apache, only observations.

> previously wrote a custom HTTP server for banner ad delivery (blazingly
> fast, 90th percentile of response times was under 35ms counting multiple
> database fetches), but if I were doing it again today I would definitely
> do it as a module for apache rather than write it full custom again.

I'd love to see SlimServer rewritten in Java. The web portion could be
deployed as a standard J2EE war file webapp. Performance *might* suffer
a bit, memory usage definitely would (anyody else here had to tune a JVM's
garbage collection settings?), but the software might gain a lot in the
translation, including cleaner development, easier code documentation
with Javadoc, cross-platform portability, etc.

Instead of MySQL, Slim could probably use something like Cloudscape, and
provide APIs (SOAP? RMI?) for manipultaing the database instead of relying
on a seperate database server process that requires its own configuration
and management. Moving to MySQL might make it easy for external apps to
manipulate the database "safely", but allowing access to the database
outside the published APIs can stifle future database development. Keeping
the database management within SlimServer also allows for things like
db update "triggers" invoking built-in routines or 3rd-party Slim plugins;
enabling a more robust security infrastructure to deal with things like
http://bugs.slimdevices.com/show_bug.cgi?id=96

Instead of targeting the Apache httpd server and mod_perl, Slim could
target the Apache group's Java software, like Geronimo/Tomcat.

Java would be nice, but what I'd really love is some good clear design
specs & documentation. Last time I really dived into the Perl code (in
the 5.4 era), I found it very tough going. I'd love to see Slim Devices
take a step back and follow a more deliberative approach.

-Peter

John A. Tamplin
2005-08-09, 17:40
On Tue, 9 Aug 2005, Peter Watkins wrote:

> I was nodding my head up til "performance enhancements". I wouldn't
> expect that, not necessarily. But neither performance concerns nor the
> notion that it's easier to secure a smaller, simpler app should be
> construed as arguments against using Apache, only observations.

Getting a simple web server to outperform Apache, with all its bells and
whistles, is quite easy in the unloaded case. Getting one that works as
well under heavy load and with dynamic content is quite a different story.

> I'd love to see SlimServer rewritten in Java. The web portion could be
> deployed as a standard J2EE war file webapp. Performance *might* suffer
> a bit, memory usage definitely would (anyody else here had to tune a JVM's
> garbage collection settings?), but the software might gain a lot in the
> translation, including cleaner development, easier code documentation
> with Javadoc, cross-platform portability, etc.

There is no point starting a language flamewar on this list. It seems
every open source app has people posting a suggestion that it be rewritten
from scratch in their favorite language -- it isn't going to happen.

perl has its pluses and minuses, but it is quite multi-platform. You can
write unreadable perl code, just as you can Java, or you can write nice
object-oriented code that is understandable by any programmer familiar
with other object-oriented languages.

> Instead of MySQL, Slim could probably use something like Cloudscape, and
> provide APIs (SOAP? RMI?) for manipultaing the database instead of relying
> on a seperate database server process that requires its own configuration
> and management. Moving to MySQL might make it easy for external apps to
> manipulate the database "safely", but allowing access to the database
> outside the published APIs can stifle future database development. Keeping
> the database management within SlimServer also allows for things like
> db update "triggers" invoking built-in routines or 3rd-party Slim plugins;
> enabling a more robust security infrastructure to deal with things like
> http://bugs.slimdevices.com/show_bug.cgi?id=96

I don't think the intention is to fix the database schema as part of a
published API, but rather to allow several processes to access the common
data store. This is one of the problems with SQLite, which
MySQL/Postgresql/Oracle/Informix/etc don't have. I think once you get
away from some of the limitations of SQLite and are using a "real"
database backend, you will be able to support multiple database backends
without any code changes. I write lots of perl code that works without
change on multiple databases -- the tricky parts are serial
fields/sequences/etc, and of course the SQL DDL is all different, but with
care the same DML can run across all of them.

You can write RPC-based APIs in any language using any database, so Java
and Cloudscape have nothing to do with that choice. If you really want to
use SOAP, it is about 20 lines of perl code to implement a given remote
method invocation because all the packages are already written, and
frankly they are easier to use than the ones in Java.

--
John A. Tamplin jat (AT) jaet (DOT) org
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723

Grotus
2005-08-09, 18:56
Dan Sully blurted out:
> * Robert Moser shaped the electrons to say...
>
>> For this:
>> Deploy our own Perl on OSX to support unicode on 10.1, 10.2
>>
>> It might be worthwhile to check out PAR
>> (http://par.perl.org/index.cgi) for this.
> Unfortunately, PAR doesn't actually bundle perl itself.
> There's also a support issue.
>
> ActiveState now has an OSX build.

According to the features page, PAR can bundle perl in two ways: pp can
build a freestanding executable, and parl can be used to run a PAR file
(or a perl app). I have no idea whether it would work with our plugin
architecture though. I also have no idea about the support issues of
PAR versus ActiveState. One other thing that PAR might be good for are
Linux variants which can't upgrade their perl installations.

Dan Sully
2005-08-09, 19:50
* Robert Moser shaped the electrons to say...

>According to the features page, PAR can bundle perl in two ways: pp can
>build a freestanding executable, and parl can be used to run a PAR file
>(or a perl app). I have no idea whether it would work with our plugin
>architecture though. I also have no idea about the support issues of
>PAR versus ActiveState. One other thing that PAR might be good for are
>Linux variants which can't upgrade their perl installations.

Again - ActiveState has a Linux build, which we'd prefer to use for support & consistency.

-D
--
Adobe Photoshop - When you want the truth. Real bad.

Roy M. Silvernail
2005-08-09, 21:48
Quoting Dan Sully <dan (AT) slimdevices (DOT) com>:

> Again - ActiveState has a Linux build, which we'd prefer to use for support &
> consistency.

Just so I understand the direction: this change means I would have to install
both an alternative Apache and an alternative Perl on a Linux box that has both
currently installed?
--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
"It's just this little chromium switch, here." - TFT
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com

kdf
2005-08-09, 22:14
On 9-Aug-05, at 9:48 PM, Roy M. Silvernail wrote:

> Quoting Dan Sully <dan (AT) slimdevices (DOT) com>:
>
>> Again - ActiveState has a Linux build, which we'd prefer to use for
>> support &
>> consistency.
>
> Just so I understand the direction: this change means I would have to
> install
> both an alternative Apache and an alternative Perl on a Linux box that
> has both
> currently installed?
>

no, just that Slim Devices wants to stick with ActiveState for building
the exe, since it will allow consistency also for osx or linux users
who cannot otherwise upgrade their perl installs. the activeState
option will exist, and will be known to work since its been used all
along.

and for apace...I believe the phrase "we're not sure yet" has already
been used to answer that.

-kdf

Roy M. Silvernail
2005-08-09, 22:30
Quoting kdf <slim-mail (AT) deane-freeman (DOT) com>:

> On 9-Aug-05, at 9:48 PM, Roy M. Silvernail wrote:

> > Just so I understand the direction: this change means I would have to
> > install
> > both an alternative Apache and an alternative Perl on a Linux box that
> > has both
> > currently installed?
> >
>
> no, just that Slim Devices wants to stick with ActiveState for building
> the exe, since it will allow consistency also for osx or linux users
> who cannot otherwise upgrade their perl installs. the activeState
> option will exist, and will be known to work since its been used all
> along.

Got it. (sigh of relief 1)

> and for apace...I believe the phrase "we're not sure yet" has already
> been used to answer that.

OK, I understand. Hope it's Apache 2.0 and that I can patch/overlay via
portage.
--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
"It's just this little chromium switch, here." - TFT
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com

dean
2005-08-09, 22:37
On Aug 9, 2005, at 9:48 PM, Roy M. Silvernail wrote:
> Just so I understand the direction: this change means I would have
> to install
> both an alternative Apache and an alternative Perl on a Linux box
> that has both
> currently installed?

Probably not, but that's why we're talking about it now so we can
make sure that we get it right.

kdf
2005-08-09, 23:02
On 9-Aug-05, at 10:30 PM, Roy M. Silvernail wrote:
>
>> and for apace...I believe the phrase "we're not sure yet" has already
>> been used to answer that.
>
> OK, I understand. Hope it's Apache 2.0 and that I can patch/overlay
> via
> portage.
>
its' going to be interesting, whatever the solution. that's for sure :)

-kdf

Triode
2005-08-10, 10:24
> My initial thoughts (and some from Robin) - and I'm not sure if this is
> feasable or not yet - is to use Apache as the handler for SlimProto &
> Streaming as well. Use it's infrastructure & socket handling, etc.
>

Don't know anything about Apache, but using something else to handle the slimproto connection may compromise the ability to do
smooth server based UI scrolling, so something to think about.... We could move display updates to UDP, take this out of the
slimproto session and do some firmware assist though to avoid this issue.

Adrian

water
2005-08-15, 03:48
If we want to support the SliMP3, there is a patch for Apache to handle UDP connections, which has not been integrated into the mainline Apache tree yet.

I'd just like to jump in here and say that I consider continued support for the SLIMP3 an esential feature of any new SS version. As it is now the SLIMP3 is the main reason I've wired my new apartment ;)

Also I'm very pleased to see the plans to move to MySQL, and on that note I'd also like to see some kind of feature to register music lp's, 7", 10", cd's & dvd's and have them show up marked as that on the "artist page" and in the browse music menu's.

:water

Carl W. Irving
2005-08-15, 12:40
Seeing that the roadmap for 7.x contemplates some pretty radical ideas (e.g., running under Apache), I guess that this is the time to ask about the overall vision of the SlimServer "service."

Right now, the monolithic nature (I'm being descriptive -- this is not a comment about whether that is good or bad) is clear and straightforward: If you want to talk to the library, you talk to the SlimServer (via the CLI, say); if you want to drive it via the web, you talk to the one and only SlimServer... and so forth.

Now that the database has been split off into MySQL, we begin to see the possibility of going straight to the database in order to get at the metadata. If the server gets further reworked as proposed for 7.x, I have to ask whether this isn't the first step towards thinking of the "server" as three distinct things:

* The "thing" that stores the metadata -- the database
* The "thing" that talks to the player -- the player controller
* The "thing" that talks to the user -- today, the web UI.

So, is this deliberate? Is it a coincidence? Would being explicit about these divisions of labor help clarify thinking -- or would it be the kiss of death a la Netscape-to-Mozilla product gap?

Just my curious $0.02...

Cwi

JJZolx
2005-08-15, 13:36
Seeing that the roadmap for 7.x contemplates some pretty radical ideas (e.g., running under Apache), I guess that this is the time to ask about the overall vision of the SlimServer "service."

Right now, the monolithic nature (I'm being descriptive -- this is not a comment about whether that is good or bad) is clear and straightforward: If you want to talk to the library, you talk to the SlimServer (via the CLI, say); if you want to drive it via the web, you talk to the one and only SlimServer... and so forth.

Now that the database has been split off into MySQL, we begin to see the possibility of going straight to the database in order to get at the metadata. If the server gets further reworked as proposed for 7.x, I have to ask whether this isn't the first step towards thinking of the "server" as three distinct things:

* The "thing" that stores the metadata -- the database
* The "thing" that talks to the player -- the player controller
* The "thing" that talks to the user -- today, the web UI.

So, is this deliberate? Is it a coincidence? Would being explicit about these divisions of labor help clarify thinking -- or would it be the kiss of death a la Netscape-to-Mozilla product gap?
From what Dan has posted in this thread I get the impression that this is very much _not_ the plan. The player controller, web interface and software supporting the remote interface will remain a single application. The database end of things remains intertwined with all of these. They're merely moving to a different dbms that requires running the MySQL engine instead of using the embedded database engine of SQLite. Likewise, the HTTP server also will be moved out of SlimServer. In the end it doesn't make SlimServer any less monolithic - it just moves critical functionality to software systems that can do it better.

dean
2005-08-15, 13:56
On Aug 15, 2005, at 1:36 PM, JJZolx wrote:
> Carl W. Irving Wrote:
>> Now that the database has been split off into MySQL, we begin to see
>> the possibility of going straight to the database in order to get at
>> the metadata. If the server gets further reworked as proposed for
>> 7.x,
>> I have to ask whether this isn't the first step towards thinking
>> of the
>> "server" as three distinct things:
>>
>> * The "thing" that stores the metadata -- the database
>> * The "thing" that talks to the player -- the player controller
>> * The "thing" that talks to the user -- today, the web UI.
>>
>> So, is this deliberate? Is it a coincidence? Would being explicit
>> about
>> these divisions of labor help clarify thinking -- or would it be the
>> kiss of death a la Netscape-to-Mozilla product gap?
>> From what Dan has posted in this thread I get the impression that
>> this
>>
> is very much _not_ the plan. The player controller, web interface and
> software supporting the remote interface will remain a single
> application.
Actually, the point of this conversation is to work out the plan. :)

From the user's standpoint, we need the software to be easy to
install, easy to learn and easy to use.

Treating it as a single visible "application" is an important way to
make it easy for users to understand what's going on.

SlimServer's performance has been hobbled by a single-threaded
application model, so splitting up the software components, and even
making them swappable or optional is under consideration.

Under the hood, it may be that we have separate software processes
(or threads) running independently for the database, web interface,
streaming, and player UI subsystems. Some folks may want to switch
out databases, add different front-ends, etc.

JJZolx
2005-08-15, 14:37
> is very much _not_ the plan. The player controller, web interface and
> software supporting the remote interface will remain a single
> application.[/color]
Actually, the point of this conversation is to work out the plan. :)
Ok, I'll throw out an idea... Without question the single biggest knock that I've heard against the Squeezebox is the clunky web UI of SlimServer. "Would love to use the Squeezebox, but I can't get past the awful web interface of SlimServer", etc., etc. (Personally, I think the web interface and client-server nature of SlimServer is ideal. I have some reservations about the difficulty and the inflexibility of the skinning capabilities, but that's probably a topic for another discussion.)

What would it take to enable the creation of a native application to control a Squeezebox? Without the need to run SlimSever, Apache, or a dbms. Ideally the dbms, database schema, etc. would be controlled by that native app. The earlier posts about using Apache to handle Squeezebox/server interaction would seem to preclude this approach.

Is it possible to create a sort of liqhtweight device driver that an application could use to operate a Squeezebox and receive commands and status info from a Squeezebox? Then the frontend could be just about anything, the database any you like, or none at all.

Carl W. Irving
2005-08-15, 20:20
Ok, I'll throw out an idea... Without question the single biggest knock that I've heard against the Squeezebox is the clunky web UI of SlimServer. "Would love to use the Squeezebox, but I can't get past the awful web interface of SlimServer", etc., etc. (Personally, I think the web interface and client-server nature of SlimServer is ideal. I have some reservations about the difficulty and the inflexibility of the skinning capabilities, but that's probably a topic for another discussion.)

What would it take to enable the creation of a native application to control a Squeezebox? Without the need to run SlimSever, Apache, or a dbms. Ideally the dbms, database schema, etc. would be controlled by that native app. The earlier posts about using Apache to handle Squeezebox/server interaction would seem to preclude this approach.

Is it possible to create a sort of liqhtweight device driver that an application could use to operate a Squeezebox and receive commands and status info from a Squeezebox? Then the frontend could be just about anything, the database any you like, or none at all.

Theoretically (i.e., I haven't tried to do it in a real application), the SlimServer CLI is what one would use to drive the system -- by system, I mean the combination of music database and players. That's what the TelCanto PocketPC app uses today and it would be fairly easy to build that level of functionality as a regular desktop application. But that's not really what you mean, is it?

The problem I see with an application that serves as an intermediary between the player and "just about anything" is that the "just about anything" is going to end up being one of two things: iTunes or Windows Media Player -- which leads to the questions of integration, DRM, etc. Sure, those are two integration applications that need to be written (along the lines of "plug the SB in, run the CD, *poof* your PlaysForSure collection is now immediately accessible"). They would broaden the reach of the Squeezebox to a vast audience, BUT...

I don't think that this is what SlimServer is or should be about. To me, SlimServer is the geek secret sauce of the Slim Devices offerings. It's what allows me to drive squeezeboxes from a Linux server in the closet. It is what sets the Squeezebox apart from yet another UPnP networked music player on the shelf at CompUSA. I realize that it isn't all that user-friendly for mere mortals, but I would be very sad if that special ingredient went away.

There is nothing wrong with having a product that appeals to the "plug it in and it just ***** works!" crowd, but I think that the software solution for that lies outside the realm of SlimServer.

Pepin
2005-08-24, 06:51
I've just updated the Software Roadmap with our goals / investigations for
the next few releases of SlimServer. Comments welcome.

I was looking at the software roadmap of SlimServer and nowhere down the road can we see a fix for bug 1026 "Implement gapless playback for MP3".

This one is a real bugger as it requires to re-encode many albums that are truly supported by SlimServer (but are not by other DAP devices that I own) thus keeping two copies of theses albums.

Do you think it is feasible to resolve that problem before 7.0 or even better, 6.5?

Regards

Stéphane Bourque

Patrick Dixon
2005-08-24, 07:25
SlimServer's performance has been hobbled by a single-threaded
application model, so splitting up the software components, and even
making them swappable or optional is under consideration.The biggest frustration for me is the ocassional lack of responsiveness of the player interface. When the server is busy, commands get queued up in the player, and then several are actioned all at once. It's impossible (as a user) to distinguish between the server being too busy, and the remote not triggering the command, so this often results in unintended actions. When those unintended actions are themselves server heavy commands (eg Browse Albums -> All, Play builds a playlist of every song in the library!!!), the frustrations are multiplied many-fold. I have clients that simply hit the reset button on the server box when this happens!

In the absence of multi-threading or interrupts, it would be far better if the SB dumped commands that it couldn't respond to within a reasonable time (say 1s), or simply maintained a 'pending' buffer of just 1 command.