PDA

View Full Version : Rewriting slimserver in another language, are you interested ?



erland
2006-12-05, 10:58
If you opened this thread and thought "oh no, not again.." this thread is probably not for you.

There has been some questions lately in different forum threads asking if slimserver could be rewritten in another language than perl.

Some questions to those of you that feel this is a good idea:
1. Why do you think it should be rewritten in some other language ?
2. Which language would you prefer and why ?
3. Would you be willing to help as a alpha/beta tester ?
4. Are you currently helping with slimserver development and are willing to share your slimserver knowledge if someone tries to rewrite it in another language ?
5. Would you be willing to help as a developer ?
6. If you are willing to help as a developer, approximately how many hours per week/month ?

I have a feeling most people asking for a rewrite aren't really willing to help or doesn't have the knowledge, but I thought it might be a good idea to check if there are any real interest in a rewrite. My guess is that it will be possible to create a slimserver with some basic functionallity in a number of months or maybe even faster, but creating a slimserver with all the current features will probably take years. All depending on which developers are willing to participate of course.

At the moment I am not certain I am willing to participate myself. After I bought my SqueezeBox and started to look at developing plugins I also felt perl wasn't the best since I hadn't developed anything in perl before, today one year later I don't see it as a big problem.

For those of you that feel a rewrite is a bad idea, please don't fill this thread with all the reasons not to rewrite slimserver. We can have that discussion when we have seen if anyone is really willing to participate in a rewrite.

JJZolx
2006-12-05, 11:25
For those of you that feel a rewrite is a bad idea, please don't fill this thread with all the reasons not to rewrite slimserver. We can have that discussion when we have seen if anyone is really willing to participate in a rewrite.
I'm sorry, but that's an unavoidable and very large part of the equation. Indeed, it's the first step before starting a thread filled with posts about just how much people hate Perl and then listening to them trash the current SlimServer.

95% of SlimServer is written by paid SD employees. That will likely _increase_ once they get some needed capital from Logitech. The whole idea is ludicrous. Just trying to get SlimProto down would be like nailing jelly to a tree. The firmware is not open source, and with firmware tied so closely to SlimServer, any new firmware released in support of the 'official' server could easily break an independent server.

I'd be happy to see the web interface language changed to php, which would open the door to many thousands of new and willing developers and maybe even break the web interface out of its current rutt. But that would probably entail moving the HTTP server to Apache. This has been talked about, even mentioned at one point as possibly part of the 7.0 release. With the whole Logitech takeover, now, I see that as unlikely. It would make SlimServer, and hence the Squeezebox family, even less of a consumer product.

Robin Bowes
2006-12-05, 11:30
erland wrote:
> If you opened this thread and thought "oh no, not again.." this thread
> is probably not for you.
>
> There has been some questions lately in different forum threads asking
> if slimserver could be rewritten in another language than perl.
>
> Some questions to those of you that feel this is a good idea:
> 1. Why do you think it should be rewritten in some other language ?
> 2. Which language would you prefer and why ?
> 3. Would you be willing to help as a alpha/beta tester ?
> 4. Are you currently helping with slimserver development and are
> willing to share your slimserver knowledge if someone tries to rewrite
> it in another language ?
> 5. Would you be willing to help as a developer ?
> 6. If you are willing to help as a developer, approximately how many
> hours per week/month ?
>
> I have a feeling most people asking for a rewrite aren't really willing
> to help or doesn't have the knowledge, but I thought it might be a good
> idea to check if there are any real interest in a rewrite. My guess is
> that it will be possible to create a slimserver with some basic
> functionallity in a number of months or maybe even faster, but creating
> a slimserver with all the current features will probably take years. All
> depending on which developers are willing to participate of course.
>
> At the moment I am not certain I am willing to participate myself.
> After I bought my SqueezeBox and started to look at developing plugins
> I also felt perl wasn't the best since I hadn't developed anything in
> perl before, today one year later I don't see it as a big problem.
>
> For those of you that feel a rewrite is a bad idea, please don't fill
> this thread with all the reasons not to rewrite slimserver. We can have
> that discussion when we have seen if anyone is really willing to
> participate in a rewrite.


I don't necessarily think that slimserver needs writing in a different
language.

However, I'd like to see it broken up into blackbox modules so each bit
could easily be replaced with a different implementation.

So, there'd be a streaming module, an web module, an IR module, a
scanner module, etc. etc.

Each of the major application processes would run as a different OS
process or in a different thread so they reply on the OS to share
execution time, not on other processes yielding in a timely fashion.

It would also be necessary to define a means by which the module could
communicate with each other.

I seem to remember posting a "blue skies" diagram some time ago. I'm not
sure what happened to that.

R.

Jacob Potter
2006-12-05, 11:58
On 12/5/06, Robin Bowes <robin-lists (AT) robinbowes (DOT) com> wrote:
> I don't necessarily think that slimserver needs writing in a different
> language.
>
> However, I'd like to see it broken up into blackbox modules so each bit
> could easily be replaced with a different implementation.

Absolutely 100% agreed there.

(Shouldn't this be in the Developers forum?)

- Jacob

peter
2006-12-05, 12:01
Robin Bowes wrote:
> I don't necessarily think that slimserver needs writing in a different
> language.
>
> However, I'd like to see it broken up into blackbox modules so each bit
> could easily be replaced with a different implementation.
>
> So, there'd be a streaming module, an web module, an IR module, a
> scanner module, etc. etc.
>
> Each of the major application processes would run as a different OS
> process or in a different thread so they reply on the OS to share
> execution time, not on other processes yielding in a timely fashion.
>
> It would also be necessary to define a means by which the module could
> communicate with each other.
>
I made the same (albeit less detailed) suggestion only last week in the
"SlimServer wants a FAST machine" thread.
> I seem to remember posting a "blue skies" diagram some time ago. I'm not
> sure what happened to that.
>
Must've missed that.

Regards,
Peter

erland
2006-12-05, 12:09
(Shouldn't this be in the Developers forum?)Yes it belongs in the developer section if we are going to discuss how to split slimserver into modules, but that wasn't the original intent of the thread.

I felt that the people talking about rewrites probably doesn't hang around in the developer section, I thought there would be a bigger chance for them to see the thread here. I might be wrong though.

totoro
2006-12-05, 12:11
I'd certainly be more likely to work on it if it were in c++. But then, someone would have to do a multi-platform build system, there would have to be a whole layer of code littered with #ifdef _linux_, etc, and we all know how fun that is. It'd probably get an efficiency boost, though.

Porting it to java seems like a waste to me, as I don't see that the efficiency gains would be all that great.

But really, I'm not sure why it would be rewritten. Has it been profiled and determined to be too inefficient based on the language? Rewriting a large scale application just for the fun of it or because one has an aesthetic aversion to the language it's written in (which I certainly have) doesn't seem like a particularly good idea to me.

pfarrell
2006-12-05, 12:26
totoro wrote:
> I'd certainly be more likely to work on it if it were in c++.

And I would not even think about it if it was C++.

> It'd probably get an efficiency boost, though.

Unsubstantiated claim. It won't make the MySql connection faster, or the
user's interaction faster, or the user's browser faster. The SlimServer
doesn't to that much that is likely to get substantially faster in any
language over another.

Which breaks the language choice down to theology. Not very useful for
discussion.

> But really, I'm not sure why it would be rewritten. Has it been
> profiled and determined to be too inefficient based on the language?

People propose rewriting it because it is not in their current favorite
language. And since it is not Snobol or Bliss, its not in my favorites
either.

Efficiency is overrated. Just go get a Quad processor system from Intel.

> Rewriting a large scale application just for the fun of it or because
> one has an aesthetic aversion to the language it's written in (which I
> certainly have) doesn't seem like a particularly good idea to me.

Correct, and changing something from the language that the current
developers
are productive in to some other language of the week is silly.

Even a gross re-architecture raises questions that are hard. Should it
be a plug=in to Apache? I'd like that, but lots of people don't want to
run a full webserver. How about some heavily marketing solution using
WebServices? Can the folks who bitch now about the Perl version running
slow on their NAS device really expect to put a pig like J2EE on their
systems?

This thread, and others like it is pretty useless, and at best belongs
over on developers.

Patches welcome.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

bklaas
2006-12-05, 12:48
I'm sorry, but that's an unavoidable and very large part of the equation. Indeed, it's the first step before starting a thread filled with posts about just how much people hate Perl and then listening to them trash the current SlimServer.

95% of SlimServer is written by paid SD employees. That will likely _increase_ once they get some needed capital from Logitech. The whole idea is ludicrous. Just trying to get SlimProto down would be like nailing jelly to a tree. The firmware is not open source, and with firmware tied so closely to SlimServer, any new firmware released in support of the 'official' server could easily break an independent server.

I'd be happy to see the web interface language changed to php, which would open the door to many thousands of new and willing developers and maybe even break the web interface out of its current rutt. But that would probably entail moving the HTTP server to Apache. This has been talked about, even mentioned at one point as possibly part of the 7.0 release. With the whole Logitech takeover, now, I see that as unlikely. It would make SlimServer, and hence the Squeezebox family, even less of a consumer product.

What JJ said. The whole idea is ludicrous. Nailing jelly to a tree pretty much sums it up. I imagine that's not going to stop somebody from trying, but I predict the chances of a community-driven rewrite of slimserver in <insert your favorite language here> being successful as near-nil. You'd be better off designing your own hardware from the ground up.

PHP implementation would make me a sad camper, because <insert your favorite language> sucks. I'd also like to think that the work done in Nokia770, Touch, ExBrowse3, and Fishbone skins are helping with the aforementioned "web interface rut".

In skin development, I don't think that Perl and Template::Toolkit pose much of a development hurdle to even the non-Perl savvy, esp. someone familiar with PHP programming. But then, there will always be somebody shouting for <insert your favorite language here>. Lucky my favorite language is Perl ;)

#!/ben

erland
2006-12-05, 12:59
Correct, and changing something from the language that the current developers are productive in to some other language of the week is silly.

This thread, and others like it is pretty uselessI know there are some very good reasons why slimserver shouldn't be rewritten in another language. I'm also not suggesting a rewrite, although it seems like I didn't make that clear enough in the initial post in the thread. A rewrite just because you doesn't know perl also isn't a good reason because it will cost you a lot less time to learn perl than rewriting slimserver in another language.

But, the purpose with the thread was to check if there are some developers available that really is willing to participate in a rewrite. I suspect there isn't but I hope they prove me wrong (if they exist).

Mostly when people are requesting a rewrite they asking someone else to do it but aren't really willing to do any work themselves.

So if you feel a rewrite is a really bad idea, PLEASE don't scare away developers who might actually be willing to do the work.

(Now, lets hope all my "good" reputation on this forum hasn't been destroyed by this thread)

bklaas
2006-12-05, 13:10
Erland, I very nearly didn't post to this thread at all because you didn't want naysayers, but how do you not reply to something that's recruiting people for something that's a fundamentally flawed idea? I don't understand the approach of drumming up volunteers, and *then* deciding whether the work is even worth doing.

Not to worry, I think you're rep is just fine. You've done nice work benefiting the slim community, and you are to be applauded for that. I'd just rather good developers in this community would be spending time working on plugins, skins, what have you, then attempting a total rewrite of a firmly established piece of server code.

#!/ben

mherger
2006-12-05, 13:14
Don't forget to ask the guy, who started a (I think) Java server a few
months back, about his experience. The announcement should be somewhere in
these forums...

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

Paul_B
2006-12-05, 13:19
I don't think Slimserver is bad, in fact I think it is quite amazing in what it does and the number of formats it supports.

The web interface performance seems to be the issue that people complain about. For example look at Mouse it is fast because it offloads the client functionallity but still uses all the excellent components of Slimserver.

Therefore, can the web build process be improved? Can more be offloaded to the client browser? Using a SB3 with Slimserver and the remote gives instant response

erland
2006-12-05, 13:21
Don't forget to ask the guy, who started a (I think) Java server a few
months back, about his experience. The announcement should be somewhere in these forums...Its actually almost a year ago:
http://forums.slimdevices.com/showthread.php?t=19843

pfarrell
2006-12-05, 13:27
erland wrote:
> Pat Farrell;159868 Wrote:
>> Correct, and changing something from the language that the current
>> developers are productive in to some other language of the week is
>> silly.
>> This thread, and others like it is pretty useless


> I know there are some very good reasons why slimserver shouldn't be
> rewritten in another language. I'm also not suggesting a rewrite,
> although it seems like I didn't make that clear enough in the initial
> post in the thread. A rewrite just because you doesn't know perl also
> isn't a good reason because it will cost you a lot less time to learn
> perl than rewriting slimserver in another language.

More than silly, a complete waste of time for all involved. IMHO, YMMV, etc.

To get serious, what goals do you see?
What defects can you fix? what enhancements will you enable?
What design and architecture do you propose to solve it?
How to you ensure it works on the variety of platforms that
are currently supported?

> But, the purpose with the thread was to check if there are some
> developers available that really is willing to participate in a
> rewrite.

As Yoda says, there is no try, only do.


> So if you feel a rewrite is a really bad idea, *PLEASE* don't scare
> away developers who might actually be willing to do the work.

I am not trying to scare anyone. I am trying to find what real reasons,
based on scientific facts, measurements, etc. are the goal.

>From years of reading the forums and mailing lists, the thing that
SlimServer needs the most is the most unlikely to ever get volunteers to
do. It needs definitions of what it does, Chris (I think) started a
thread over on developers and the wiki trying to say that. It needs QA.
It needs people to test it on weird platforms, and with weird setups.

For example, I used it totally happy on Mandriva starting with Mandrake
9. Then I moved to Mandrake 10, and Mandriva changed its name, 10.1,
2006. Now I'm trying Mandriva 2007. Installing it is a challenge.
Something that Mandriva's packaging guys did makes the SlimServer
unhappy. It takes days to figure this stuff out. At the end, you have
a SlimServer running on the same box, playing the same music that you
started with. There is _zero_ sex appeal in doing this.

Another clear example is instrumenting the code and finding out what is
slow, where the memory problems are, and either fixing them, or making
it easy for the developers to replicate and fix them. Again zero sex
appeal, but critically needed.

It is a ton more fun to pick a new language and hack something from
scratch. It is a lot less fun to make something pretty damn good be a
little better.

If anyone knows how to make RPMs, please contaxct me via email, so I can
get a nice Mandriva-friendly RPM of 6.5.1 working. I don't speak RPM
this week, but soon.

--
Pat pfarrell (AT) pfarrell (DOT) com
http://www.pfarrell.com/music/slimserver/slimsoftware.html

bklaas
2006-12-05, 13:30
The web interface performance seems to be the issue that people complain about. For example look at Moose it is fast because it offloads the client functionallity but still uses all the excellent components of Slimserver.

Therefore, can the web build process be improved? Can more be offloaded to the client browser? Using a SB3 with Slimserver and the remote gives instant response

That's exactly what putting AJAX in the web interface does-- offloading the interface to the client side. I didn't put AJAX in all elements of Touch/Nokia770, but you should get great performance from the 'now playing' and 'playlist' pages.

The promise of the web interface over something like Moose is true cross-platform compatibility. Of course, cruddy things like the IE browser hamper that promise, but suffice it to say the only reason I haven't checked out Moose is because I don't use windows.

#!/ben

JJZolx
2006-12-05, 13:40
The web interface performance seems to be the issue that people complain about.

Web interface usability complaints are a close second, although from an immediate, practical standpoint, the ongoing performance issues are a far greater problem.

Throwing new skins and AJAX at the exact same web interface that hasn't changed in years is like putting lipstick on a pig.

Paul_B
2006-12-05, 13:43
Bklaas,

Is the Ajax style included in the 6.5.1 nightly release or only in the 7.0 trunk?

As for Moose I was trying to illustrate it isn't necessarily all of Slimserver with "poor" performance. As for cross-platform compatibility well it is good to have. But then to some extent is code designed to take advantage of specific OS calls for performance.

I am not getting into a Linux over Mac over Windows as I have made my career on Windows (although have supported Macs in the past as well). Linux seems to have made its mark as well look at all the NAS devices. I can't add value in the programming language as I only script in VB or sometimes Java.

But if the web browsing functionality of Slimserver is improved then it will silence this argument

totoro
2006-12-05, 13:43
totoro wrote:
> I'd certainly be more likely to work on it if it were in c++.

And I would not even think about it if it was C++.

> It'd probably get an efficiency boost, though.

Unsubstantiated claim. It won't make the MySql connection faster, or the
user's interaction faster, or the user's browser faster. The SlimServer
doesn't to that much that is likely to get substantially faster in any
language over another.

Which breaks the language choice down to theology. Not very useful for
discussion.

> But really, I'm not sure why it would be rewritten. Has it been
> profiled and determined to be too inefficient based on the language?

People propose rewriting it because it is not in their current favorite
language. And since it is not Snobol or Bliss, its not in my favorites
either.

Efficiency is overrated. Just go get a Quad processor system from Intel.

> Rewriting a large scale application just for the fun of it or because
> one has an aesthetic aversion to the language it's written in (which I
> certainly have) doesn't seem like a particularly good idea to me.

Correct, and changing something from the language that the current
developers
are productive in to some other language of the week is silly.

Even a gross re-architecture raises questions that are hard. Should it
be a plug=in to Apache? I'd like that, but lots of people don't want to
run a full webserver. How about some heavily marketing solution using
WebServices? Can the folks who bitch now about the Perl version running
slow on their NAS device really expect to put a pig like J2EE on their
systems?

This thread, and others like it is pretty useless, and at best belongs
over on developers.

Patches welcome.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html


I'd say that turning it into an apache plugin would be at least as silly as a wholesale rewrite. At least a rewrite, if it worked, wouldn't make end users miserable.

As far as the efficiency thing goes: you can't expect users to get a quad processor machine for slimserver. :). You'll note that I said it would _probably_ get a speedup, not that it would necessarily. That being said, given the better support for concurrency, better profiling tools, etc available in c++, and the fact that in general it's just a lot faster (given equally well written code in both languages), I'd be pretty surprised if it didn't get sped up.

Really, I think we're in agreement. IMHO, the whole idea is bad, unless there is some really compelling reason for it. It seems that everyone is in agreement that there is not.

pfarrell
2006-12-05, 14:11
totoro wrote:
>> Efficiency is overrated. Just go get a Quad processor system from
>> Intel.
>
> As far as the efficiency thing goes: you can't expect users to get a
> quad processor machine for slimserver. :).

How long do you think we'll go before you can't buy a "pc" that isn't
at least dual core. I think all the Macs are already. Its just a matter
of time. My SlimServer is an ancient crock box I had laying around.
The first one was a P3-500, the current one is some AMD 2400+.
My next real computer will be dual if not quad, and in a few years, it
will be too slow for work, and will become a slimserver.

> would _probably_ get a speedup, not that it would necessarily. That
> being said, given the better support for concurrency, better profiling
> tools, etc available in c++, and the fact that in general it's just a
> lot faster (given equally well written code in both languages), I'd be
> pretty surprised if it didn't get sped up.

You're again getting into religion. The concurrency issue is debatable.
The important thing is that the SlimServer is a GUI/Database program.
Nothing is going to speed those parts up as long as they are sequential.
And splitting them into threads, processes, tasks, etc. is doable in any
modern language. The SlimServer just doesn't do that much.


> That being said, the whole idea is bad, unless there is some really
> compelling reason for it. It seems that everyone is in agreement that
> there is not.

Agreed.
There are other, low hanging fruit.

And while they are at it, can someone please kill off the evil MP3
ID3.v1 tags....
--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

totoro
2006-12-05, 14:21
totoro wrote:
>> Efficiency is overrated. Just go get a Quad processor system from
>> Intel.
>
> As far as the efficiency thing goes: you can't expect users to get a
> quad processor machine for slimserver. :).

How long do you think we'll go before you can't buy a "pc" that isn't
at least dual core. I think all the Macs are already. Its just a matter
of time. My SlimServer is an ancient crock box I had laying around.
The first one was a P3-500, the current one is some AMD 2400+.
My next real computer will be dual if not quad, and in a few years, it
will be too slow for work, and will become a slimserver.

> would _probably_ get a speedup, not that it would necessarily. That
> being said, given the better support for concurrency, better profiling
> tools, etc available in c++, and the fact that in general it's just a
> lot faster (given equally well written code in both languages), I'd be
> pretty surprised if it didn't get sped up.

You're again getting into religion. The concurrency issue is debatable.
The important thing is that the SlimServer is a GUI/Database program.
Nothing is going to speed those parts up as long as they are sequential.
And splitting them into threads, processes, tasks, etc. is doable in any
modern language. The SlimServer just doesn't do that much.


> That being said, the whole idea is bad, unless there is some really
> compelling reason for it. It seems that everyone is in agreement that
> there is not.

Agreed.
There are other, low hanging fruit.

And while they are at it, can someone please kill off the evil MP3
ID3.v1 tags....
--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html
Isn't support for threads in perl just fork? That's a pretty horrible way to do concurrency vs threadpools, etc, that you can get in languages like c++ or java, and a great way to get a lot of really evil heisenbugs. I've honestly never heard anyone claim that perl was a good language for concurrent programming. But you're right, this is a theological conversation at this point :). I'm not advocating a rewrite any more than you are.

erland
2006-12-05, 14:23
To get serious, what goals do you see?The goal with thread was really to get no responses. My feeling is that some people complain about the language choice but none of them is really willing to do any work, the idea with the thread was to check if this really was the case.

Personally I'm quite happy with the current slimserver. A year ago I was very skeptical to perl since I hadn't programmed a line of perl code. I choosed to accept the fact and started to learn perl and a few plugins and a year later I am still learning. Today I don't see perl as a problem. The only goal I personally can see with a rewrite is that the language choice shouldn't scare away potential developers, today I think this is the situation in some cases.

What defects can you fix?A rewrite would obviously not fix any defects, it would create a whole bunch of new ones.

what enhancements will you enable?More developers => More plugins => More features. (In the long run)
The slimserver core would obviously have less features for a long time in a rewrite, I'm aware of the fact that it would take a lot of time to implement all the current feature.

How to you ensure it works on the variety of platforms that are currently supported?This is probably one of perls strong sides. Almost any other language would probably result in less supported platforms. Java which is platform independent in some way (write once, test everywhere) is one solution, but I am not sure its a good choice due to the realtime requirements. Also Java is probably a bad idea for devices such as NAS boxes with slow processor and little memory. So I guess, what I am saying is that a rewrite would probably result in less supported platforms.


SlimServer needs the most is the most unlikely to ever get volunteers to do. It needs definitions of what it does, Chris (I think) started a thread over on developers and the wiki trying to say that. It needs QA.
It needs people to test it on weird platforms, and with weird setups.Completely agree with you here, this seems to be the issue with many open source projects. Probably because they often start with a single developer starting to write code without any real requirements, at least not any written requirements. The concept often seems to be "code first", "documentation later". Now, I am not saying that this is the situation with slimserver, because I don't know enough of its history to know if thats the case or not.


It is a ton more fun to pick a new language and hack something from scratch. It is a lot less fun to make something pretty damn good be a little better.Some developers are really just interested in the "fun" part, fortunately enough there are also a few that are looking for the challenge to make something good even better. But my personal feeling is that it might be possible for the ones looking for the "fun" to also provide something useful. As an example when someone complains about the language choice the response is often just a short "patches welcome" or a little longer explanation why it's useless to change the language. Maybe it would be a better choice to really question what they want to do and give them some idea on how to do it. As an example some might want to do a nice looking client, this is really possible to do in their own language, for example Moose is a great example of this.

bklaas
2006-12-05, 14:34
Bklaas,

Is the Ajax style included in the 6.5.1 nightly release or only in the 7.0 trunk?


Yes, and I added IE support to Touch just a week or two ago in both 6.5 and 7.0 branches. IE is terrible with CSS standards, and I had to hack it considerably for that to work across browsers.

FWIW, Touch in 7.0 has some really nice enhancements to the 1-by-1 artwork browse that you won't see in 6.5.



I am not getting into a Linux over Mac over Windows as I have made my career on Windows (although have supported Macs in the past as well).

Linux vs. Mac vs. Windows is not my argument. Choice vs. Non-choice is the argument. The grand majority of software products available both in this space and almost any space are Windows-only. I have nothing at all against someone in the community developing Moose or other platform-dependent software, but I would hate to see a platform-dependent move from slimdevices in either slimserver or a GUI interface. Luckily, I think there's very little chance of that happening since a) lots of mac and linux users (in relation to market share), b) even higher proportion of linux developers (in relation to market share).

On the GUI interface thing, there's a little voice that sometimes whispers in my head (I'm weird that way), and it whispers "XUL".
kind of like what the songbird folks are doing, but with slimserver love:
http://www.songbirdnest.com/
interestingly one of the screenshots they present on the features link is of the slimdevices website (???)
As said in Ghostbusters: "There is no Dana. Only XUL[sic]"

Platform-independence is not the easy way, but in this case IMO it's the right way. At least for me, it's what brought me to purchase a squeezebox, as well as to develop skins for slimserver.

#!/ben

peter
2006-12-05, 14:43
Pat Farrell wrote:
> Even a gross re-architecture raises questions that are hard. Should it
> be a plug=in to Apache? I'd like that, but lots of people don't want to
> run a full webserver. How about some heavily marketing solution using
> WebServices? Can the folks who bitch now about the Perl version running
> slow on their NAS device really expect to put a pig like J2EE on their
> systems?
>
The performance of software like Moose (I dont like it much because I
prefer to browse my music folders by directory) show that a frontend
that talks to the CLI interface can be pretty snappy. I figure a good
PHP frontend that talks to mysql and the server via the CLI could
already be built. I'd like to see one, so if anyone's looking for a
project...

OTOH there's no reason why the webserver couldn't be a standalone perl
script...
> This thread, and others like it is pretty useless, and at best belongs
> over on developers.
>
Discussion is never useless.

Regards,
Peter

bklaas
2006-12-05, 14:43
Isn't support for threads in perl just fork?

No.

Google perl + threading
http://www.google.com/search?q=perl+threading&sa=Google+Search

totoro
2006-12-05, 14:51
No.

Google perl + threading
http://www.google.com/search?q=perl+threading&sa=Google+Search

I stand corrected. Just goes to show how current my perl knowledge is. :) I like the fact that lock works using something like RAII.

so my discussion with pfarrell really was equivalent to:

emacs
no, vi
no, emacs

etc :)

Paul_B
2006-12-05, 14:59
Peter,

You hit the nail on the head with what I was waffling on about. Moose is fast as a client to access the backend Slimserver.

I don't like the interface of Moose but only because I love Fishbone. But Moose is very fast in comparison to web interface.

Personaly I agree with a nice broad spectrum of OS. Linux is wonderfully customisable (both a strength and weakness), Macs have a wonderful interface. Windows is incredibly easy to install and get support.

pfarrell
2006-12-05, 15:20
totoro wrote:
> so my discussion with pfarrell really was equivalent to:
>
> emacs
> no, vi
> no, emacs

Or as Disney did in "Sleeping Beauty"
pink
no, blue
no, pink
....

I'm actually a vi guy, but I do have friends who do emacs.

Its all about the music. And I just got my transporter, have to unpack it.
--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

kdf
2006-12-05, 20:00
JJZolx wrote:
> 95% of SlimServer is written by paid SD employees.
not that anyone is counting lines or anything...
-k

pfarrell
2006-12-05, 20:02
totoro wrote:
> bklaas;159923 Wrote:
>> No.
>>
>> Google perl + threading
>> http://www.google.com/search?q=perl+threading&sa=Google+Search
>
> I stand corrected. Just goes to show how current my perl knowledge is.
> :)

The interesting thing about this business is that over time, all things
gather, include, or steal, all good ideas from other tools.
Been this way about databases, languages, operating systems, etc.

Clearly at least since Xerox Parc invented WIMP, and probably going
back to Eckertand Mauchly, or Alan Turing.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html