Talk:Playlist refactor

Is there going to be a medialib refactor in a similar fashion? It would be great to allow different medialib backends in the same way. Postgresql for all the people that want to omfg-optimize their medialib processes, and possibly different sqlite table types for people who want really lightweight medialibs (i.e. me ;) --dan

no -- tobias

super --puzzles

A longer answer: No, because making the SQL backend switchable will result in a lot of problems for the client authors, since we allow direct access to the DB via SQL queries. Imagine the end-user horror. "OMGWTFBBQ gxmms2 doesn't work with my db, it gives me 1000 sqlerrors KTHXPLZ" or "OMGFFSWTFKORV when I run this special client made by a client author that want a oracle backend it doesn't work with sqlite!!!! PLZFIX! KTHXPLZ!"

-- tobias

that is understandable --puzz

Back-end configuration?

In my opinion, all playlists should always be stored in the database, even when dynamically generated. Otherwise, you would have playlists that do not resume with the same content when you restart the server, which is not very intuitive.

The system tru described sounds sane to me, basically a system of server-side hooks which would manage the behaviour of the playlist. Originally I thought of doing something similar client-side but clearly, it's cleaner if it can be done on the server so we avoid clients competing to run their own hooks.

The back-end system would allow iTunes-like smart playlists, by feeding the playlist with entries randomly queried from the medialib, or possibly from other playlists.

However, one point remains blurry for me. Obviously, the clients will want to customize advanced backends (e.g. choose the number of songs in history, or the query to find entries to enqueue). Such a mechanism could be rather easy for simple config values (number of songs as integer), using playlist_backend_config_{set/get} functions for instance. But how about the "query to find entries to enqueue"? Either it would be an abstract structure (adds complexity, needs to be defined), or simply a query string. In the latter case, clients would have to do two transformations: Filter-UI -> query *and* query -> Filter-UI. Sucks.

Any ideas on this?

--Theefer 19:59, 20 Feb 2006 (CET)

I would store the SQL-query within subsets/dynamic lists and limit the query style to primitive functions. Just simple compare operators like "=", "LIKE", "<", ">", "!=". This is an easy alternative to a whole abstraction layer which all in all also would end up into that primitives. Those queries could easily be stripped down into their parts and then could be displayed colorful! ;) What we might left out is the prefix "SELECT * FROM Media" which is obvious. --Karsten 00:14, 21 Feb 2006 (CET)

I had something pretty similar to Karsten's suggestion in mind. Except that sql is a tiny bit more abstracted away. I'll try to make a description of that later. Anders Gustafsson 22:43, 22 Feb 2006 (CET)