MLQ (Media Library Query) file format and mime type proposal

[Milosz Derezynski]

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

On 6/22/06, Josef Spillner <spillner at kde.org> wrote:
>
> 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
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20060622/e4555d19/attachment.htm