Query() shouldn't be translated (or there should be a more parsable version)

[Wojtek Jurkowlaniec]

I was checking how dbus communication works in exaile. Everything is fine except for the Query() command.
In my opinion it shouldn't be translated.
If somebody wants to create program which gets the information about currently playing song, he has to deal also with translations.
so my suggestion, and very simple patch not to translate dbus information.

[reacocard (reacocard)]

Query isn't really intended to be machine-parsable, its main reason for existence is to support the --query commandline option, which is intended to be human-readable and which should therefore be translated.

At present, using GetTrackAttr is the best way to get machine-suitable values. We've been discussing this in IRC a bit though and are considering adding some new method (GetTrackAttrs?) that would dump all the metadata about the current track to XML and return that over DBUS, which would both be faster (when using many tags, since you only need one round-trip) and would make it much easier for clients to support a greater variety of information and formattings. We could also then implement --query on the client side and deprecate the DBUS Query method, since it doesn't really make sense as part of the api exposed to other applications.

[Johannes Sasongko (sjohannes)]

A few points:

1. I think it's still important to make Query non-translatable to fix the behaviour of existing clients.

2. We can either provide a simple artist-album-title info (where I recommend a simple key=value format) or a dump of the track's tags. For the latter, it probably makes sense to have it in JSON or XML -- I prefer JSON for less ugliness, but the json module only becomes part of Python stdlib in 2.6.

3. When implementing a Query replacement, don't forget that it also needs to return the playback state.

[reacocard (reacocard)]

1) What existing clients? AFAIK, the only people using this are people parsing --query in their own personal scripts. which can make whatever assumptions they want to, including a static locale setting. And as I noted, proper DBUS clients can easily work around the problem by using GetTrackAttr instead.

2) I don't think there's a whole lot of point in only doing it piecemeal, though we could allow clients to pass in a list of tags that they want to see, to avoid having to send all tags all the time (with some way to also get all tags - empty list?). I agree json is less ugly, but we're already using python's xml libraries so reusing that reduces memory overhead marginally, and in general desktop app developers are probably more familiar with xml than json at this point. The fact that json is only available in 2.6+ is a moot point, seeing as 0.3.3 will depend on 2.6+ anyhow.

3) True, though we could just take the extra expense and make a second dbus call to get that. The cli parameters already spend far more time just warming up python and importing modules than they do on the actual dbus calls, so i doubt the overhead would be at all noticeable in this case.

[Mathias Brodala (mathbr)]

Should be fixed since r3964 with the new --format-query and --format-query-tags CLI calls (DBus: FormatQuery)