@freek wrote:
I fact, I’m talking about a caching layer between the database and the clients.
It’s possible. But that would be way too much work for such a simple task. And it would be an extra process simply for caching firefly’s DAAP requests.
The next problem would be, how to cache different requested values.
DAAP returns assembled lists in the order values get requested.
f.e. a request only asks Title, Artist.
But iTunes requests multiple values, in a different order. This would result in a different list. All these different lists would have to be cached. Not quite efficient as you can imagine.
I can imagine the easiest way to crank up the performance on iTunes is hard-coding in firefly itself. There should be a way firefly can ‘determine’ the client application like iTunes. If this is the case, it can be filtered and sent the pre-cached iTunes DAAP list.
The problem this causes is difficult maintenance. If iTunes requests different values in future updates, the cached list will be wrong. You’d have to cache the different type of lists for each version of iTunes.
So I don’t think it will be do-able to actually cache a DAAP list or crank up the performance in iTunes.
(This performance issue actually made me write DaapPlaylistGenerator from the Add-On Software forum, to put the “cached list” into a .m3u and play using Winamp. :))