[Feedback] DBus Interface Needed Enhancements

[Sébastien Laoût]

Maximilian Kossick wrote:
> On Sunday 12 August 2007, Ian Monroe wrote:
> > The database should not be designed with script writers in mind. It's
> > impossible for us to guarantee that there won't be changes. But we
> > should make the 'query' call an absolute last resort, and instead have
> > a DBus interface to do all the sorts of things that query is currently
> > being used for.
> 
> I am planning to add a XML-based query language to the Amarok DBUS interface 
> at some point. The XML-format will basically be the same as the one used to 
> store smart playlists, with a few extensions to make it possible to define 
> the required return values. We might be able to remove the current SQL-based 
> query method afterwards.

The XML-based query language might be a very good jump.
I would do only a small number of DBus calls on each song change, instead of 
querying the artist name, and then the album name, cover path, etc.
This should be faster.
Just make sure it is not too complicated to use, for eg. script languages 
where XML is not easy to use.

But before removing the query() method, please make sure ALL informations are 
available by the way of DBus calls.
And by "ALL", I mean "all PRESENT and FUTURE informations".

Another use-case that I forgot to mention:

  => Allow people to see tags assigned to a played song,
     and to assign & remove tags from that song.

"Assign tags" means that the script needs a way to retreive the list of all 
available tags from Amarok, need a way to add, remove or edit tag names, etc.
So, please make sure those things are doable without using query().

For me, tags are of the same sort of use than star rating: useless with Amarok 
only, totaly essential with a good GUI.

I mean, without Kirocker Music Display, I would not use stars. Why? Because 
when I play a song I do not know if it already has stars, what rating it has.
If I want to assignate a rating to the song I must open Amarok main window, 
figure out where the current playing song is in the playlist, either 
realise "oh, I already rated it => close Amarok" or "Ok, let's click the 
stars to rate it and close Amarok". After a few times, I would have 
abandonned the idea of rating my songs because it's too complicated. With 
Kirocker Music Display, if I hear a song I love, I move my eyes to the applet 
and either see it's already rated, or only have one click to rate it, and 
then I can go back to my current work.

To make that story short: tags are too complicated and too slow to use right 
now in Amarok. But provided by a very quick and easy interface like Kirocker 
Music Display, it has the potential to become a very very powerful and smart 
way to organize our musics.

For myself, I love metal and rock, but when doing parties I need "cooler" 
songs (less trashy ;) ), so whenever I find a song that is very calm, I would 
assign the tag "Calm" to it, and it will be ready to play on the next party. 
With the current Amarok, going to song properties and clicking the Tags tab 
is a too high barrier for me to do so.

Retreiving the list of tags is impossible with the current Amarok DCop 
interface. I belived I had to abandon the tagging feature until I found that 
I could query the database interface.

Sure, removing query() and providing more developer-friendly ways to do things 
is the way to go, without any doubt.

But when developers added the tag feature they forgot to add all corresponding 
DCop methods. Or it's not forgetful, it's also that Amarok developers can't 
predict every uses script developers will imagine. That's what I call 
important for "future features": either you make sure new features will be 
also fully available through DBus, or you keep the query() method to keep 
script developers free to use workarrounds for uses that Amarok developers 
were not able to predict.