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. -- mwatkins ------------------------------------------------------------------------ mwatkins's Profile: http://forums.slimdevices.com/member.php?userid=7867 View this thread: http://forums.slimdevices.com/showthread.php?t=28414 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
