"Steinar Bjaerum" <[EMAIL PROTECTED]> writes: ... >> I get what you're saying. I have to wonder though if it's worth the >> effort to define a new format, if slim is the only one using it? Or >> are you suggesting picking one of the four previously mentioned, and >> provide scripts to translate the other three (and perhaps others) into >> the chosen one, instead of supporting each directly in the server? >> What would be the advantage to the end user to make this translation, >> in addition to whatever format they currently prefer? ... > > The chosen format could very well be one of the existing formats. > Possible advantages of choosing a slim-preferred format: Easier maintainance > resulting in rock solid operation, it might be easier for non-experts to > develop the utilities than to do development inside slimserver itself, ... > > It could be that supporting/maintaining the different formats inside > slimserver is not that big deal and that it is easy to get acceptance for > inclusion of new formats. If so, it is probably not worth to pursue these > ideas further. I guess you Michael are the best one to do such an > assessment.
I don't know if I'm the best one for that. I just throw patches at the slim folks every now and then. And I'm certainly not the only one that messes around with that part of the code, so I'm probably not in a position to make an accurate assessment. As for me, I'd like to see a (mostly) standard format emerge too. So far however the number of contenders has been small enough that it hasn't been too much trouble. Especially since some of them are things we deal with in the code anyway, such as parsing cuesheets. As long as the number of supported formats goes down over time and not up, we're probably in ok shape. -michael -- "kipple drives out nonkipple" _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
