mwatkins;144231 Wrote: > I can't believe that the queries used by slimserver couldn't be > abstracted sufficiently to avoid issues with various flavours of SQL. > Its not like the queries needed to support a music catalogue are rocket > science. > > While its true that there are a great many differences between the > various implementations of SQL, for a tool with needs as simple as > slimserver's, using a middleware layer to hide those differences would > have been an appropriate, even advantageous, decision. > > Sure, taking the middleware db-abstraction approach would have resulted > in more databases being used, with a corresponding impact on support > queries from the multitudes. I understand that, but I don't agree with > the decision. > > A better decision would have been to use db-abstraction in the core, > but announce support only for a single database, MySql if that is your > choice. Solve the supportability issue by decree, rather than limiting > the scope of the software's appeal. At least then you aren't walling > the software off from others who might be interested in different sorts > of mashups which might prove interesting to the community. > > This isn't about being married to one technology, or me or others being > biggoted against another. Given that there are a plethora of > db-abstraction layers out there, and slimserver's db requirements are > practically infantile, the decision smacks of poor product management > choices. > > PS: Good point about the implementation language. Always felt Perl was > a poor choice for slimserver, but I grinned and bore that. But the > difference is significant: perl I already must support on a wide fleet > of machines at work and at home; MySql I do not have to support nor > care to add it to the mix. Chances are that I will explore other > options rather than invest in a new upgraded box for home, or one for > the office I'd planned to add. What was once a no brainer decision for > me now is less so. > > I doubt my apparent reluctance to upgrade due to MySql dependency is > going to be commonly shared, but certainly there will be some who feel > as I do. Enough to matter, from a sales perspective? Perhaps not.
I think the fact that scan times improved with MySQL might not mean that MySQL was needed. It could also be evidence that there was something wrong with SS. I too have my doubts that PERL is the right choice for SS. I really don't see why a full-blown transactional db back-end should be needed, even with tens of thousands of tracks. I agree, buying more SBs would be a no-brainer if not for SS. SS is clearly the weak link in the whole SB proposition --the UI, the db, the performance...perhaps it's time for a complete re-do guys... I know you guys love hardware (and, kudos, it really shows in the product) and the current SS is already developed, but if it were my money, I'd be taking a long hard look at slimserver. -- rudholm ------------------------------------------------------------------------ rudholm's Profile: http://forums.slimdevices.com/member.php?userid=2980 View this thread: http://forums.slimdevices.com/showthread.php?t=28414 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
