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. _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
