Yeah well just to stay within the focus of a music library, there has to be something that does the resolution. ONE possible option would be to specify a D-BUS interface name, and a have simple launcher. All apps supporting MLQs would have to have a minimal common subset of D-BUS interfacery to allow this kind of query to be sent to them in some way (something like an AddUri call might just suffice), then the launcher would basically consist of starting the relevant apllication trough D-BUS activation, and then pass on the actual query to it. (We have a dummy method "Startup" on our D-BUS iface which does nothing, but causes D-BUS to start up BMP. The reasoning is that we have one main binary and one "remote" binary, which is though set so that it is perceived as being the main binary, as in it's in /usr/bin, whereas the -bin (main) binary is in /usr/libexec. The reason is so that we have a lightweight remote app that can perform actions on the main binary and don't have to have the main app be capable of being a client to it's own server and have all the startup shizzle going just to perform a certain remote operation). For example you'd have: query://org.beepmediaplayer.bmp/?artist=Air&Album=Moon%20Safari The script, or be it a binary, let's call it "play-mlq", would launch the player with the specified interface and pass it the actual query. _Another_ possibility, although this would require players that can work with mutable playlists like BMP, is that it would pass the query on to e.g. something like Tracker or some other indexer, which would then execute the query and _IT_ would then start the player specified by the interface and pass it along the resulting URIs. -- Milosz <div>On 6/22/06, Josef Spillner <<a href="mailto:spillner@kde.org">spillner@kde.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Alle 11:25, giovedì, 22. giugno 2006, Milosz Derezynski ha scritto: > Since this is very common, and having the discussions about a common music > database in mind, this seems like a useful proposal, since it is not player > specific. It is not even music specific. I've used query:// URIs for a long time with metaservers, although only in a read-only context, whereas for write access the (alternative) full-blown XML interface is used. The way it is used for the metaserver is like query://type/category, where e.g. type would be the generic name for a server (say, 'freeciv' or 'cupsd') and category would be 'connection' (to get back a connection URI) or 'meta' (to get back other metaserver URIs for the same type). Using such a scheme makes an application resistant against host name changes in the long run, i.e. it will pick up moving servers automatically. This is probably not the same thing as your query, but obviously it's also used to query a database behind it (which is a XML database in my case, but could be SQL or anything else for that matter). So maybe it makes sense to standardise this in a broader context. KDE Radio Station is one example where this is used (ha - found a relation to music!), and the GGZ Gaming Zone project is another one (where it originated since metaservers are commonplace with game servers). Josef _______________________________________________ xdg mailing list <a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xdg">http://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div>