Max Kellermann writes: > On 2013/10/20 09:22, Jean-Francois Dockes <j...@dockes.org> wrote: > > The existing ProxyDatabase plugin is not configured in the default mpd, and > > not usable anyway. > > Why do you think so? I've been using it for a while.
I have tried it with phpmp, and while I can't claim that nothing worked, I seem to remember that not much did. Possibly, I just did something wrong. Can't check now, I am not at home for a few days. If the current version actually works properly, then, obviously, the patch is of no value, please ignore it. > > The Database plugin interface currently assumes that a recursive walk of > > the database can generally be done, and that it can be used for > > searching. > > Why makes you believe that? What part of the DatabasePlugin API does > that? The thing that made me believe this is the "recursive" field of the "selection" parameter to Visit, and the fact that the existing implementation in ProxyDatabasePlugin.cxx was recursive. I'm quite glad to have been mistaken, this means that implementing support for UPnP will not need an API change which is really great news ! > > In the case of a song search, I appear to be bound, because the Visit() > > API method seems to require a recursive tree walk and the songs are > > filtered during the walk. > > No, you don't even need a recursive tree walk there. You can still > pass all the criteria to MPD - all but one: the base URI, because the > MPD protocol can't limit a search to a sub directory. Ok, that's great. So the tree traversal aspect can be completely ignored, and everytime "recursive" is set, we are actually always performing a search, to be implemented as seen fit ? > So you have two choices: > > - start walking recursively at the specified base URI and do matches > locally (what ProxyDatabasePlugin does currently) Ok, very slow, and does not work at all with UPnP as far as I understand (but I seem to have trouble with the "understanding" thingy currently, so maybe I'm wrong again). > OR > > - pass the criteria to the other MPD, i.e. let it match - and discard > all results that are outside of the base URI This is probably the best approach for me at this point, I still have to study the commonly available search capabilities in UPnP MediaServers, but a combination of delegating to the remote and local post-processing seems the most adaptable approach. > and maybe a third choice: > > - implement support for base URI matching in MPD, so this one can be > passed, too - allowing our MPD to marshal the whole > DatabaseSelection object into a request to the other MPD Yeah... Given my brilliant understanding of the MPD code, I don't really feel like trying to modify the core :) I feel safer with plugins for the moment. > > In the case of a remote UPnP MediaServer, a tree walk is mostly > > impossible: > > And you don't need it. Great ! Can't work on it this week, but I'll get back to it the week after, and with this new information, I'm quite hopeful. Cheers, jf ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
