[Feedback] DBus Interface Needed Enhancements

[Maximilian Kossick]

On Sunday 12 August 2007, Ian Monroe wrote:
> On 8/12/07, Miguel Angel Alvarez <maacruz at gmail.com> wrote:
> > Hi all,
> > I want to add my little grain of sand to the ongoing dicussion (Who is
> > me? See replaygain plugin)
> > I don't know how the new dbus interface will be, so I can't talk about
> > it, but I know the current interface.
> > I usually don't like the idea of breaking backwards compatibility and big
> > api/interface changes, unless it is absolutely needed (if it works, don't
> > fix it). Having said that, in this particular case, the new dbus
> > interface is, by itself, a complete departure from dcop, so it could be a
> > good oportunity to change whatever needs to be changed, but no need to
> > throw away the current system.
>
> Makes sense.
>
> > The current script interface allows quite a number of things, and in some
> > aspects it is very complete, but in other aspects it is severely lacking.
> > I think the actual number of dcop calls is mostly very complete. Almost
> > every aspect can be controlled with a dcop call. Also, the notifications
> > method is very simple, making very easy to write plugins.
> > The notifications are very scarce. There are quite a number of events the
> > scripts can only know by polling with dcop calls (for example, user
> > driven track changes, playing mode changes, configuration change...),
> > which is not good, and still worse, there are some events that the
> > scripts have no absolutely way to know about (for example, database
> > events). This limits greatly what plugins can do or what plugins can be
> > written.
> > Notifications should be providen for any event which causes a  change in
> > amarok state or behaviour.
>
> DBus has a proper signal system, so thats helpful.
>
> > The database could see some small improvements: some simplified query
> > mechanism, some way to add fields to save plugins related information...
>
> 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.

> > Another problem is response time.  In some cases a great problem, indeed.
> > This time can be in the order of seconds! in extreme cases. Obiously,
> > this greatly hurts interactivity and coupling (for my plugin that's a
> > major problem). This should be corrected.
> > Related to this, many things happens at trackchange time, and some of
> > them have high cpu load, while it is not important that they are highly
> > sinchronous with the track change (like cover art and context pane
> > rendering).
> > So, to avoid such concentrated load, I suggest launching such tasks some
> > small time (like 0,1 or 0,5 seconds) after track change in their own low
> > priority thread. May be, plugins could request high priority to get some
> > preferential treatment?
> >
> > Other thing people complain about, is the lack of sound processing
> > plugins. I think that support could be (easily?) added for such plugins
> > by providing a way access the wave bytestream, just before it is sent to
> > /dev/pcm, by using pipes or sysv shared memory. Just imagine the whole
> > new world of posibilities this would open... sound normalization,
> > filters, effects ....
> > Could it be done?
>
> Amarok still doesn't do anything with stuff like /dev/pcm but relies
> on Xine. Phonon does have an effects system, but I don't know whether
> something like sound normalization could be done with it.
>
> > As a final suggestion, may be we should start a wiki page about this?
>
> I agree. I think the script writers would be the ideal folks to design
> a new DBus API. Implementing the API would be a good junior job, the
> next time someone says they want to work on Amarok we could just point
> them to the wiki page.
>
> Designing the API will be a challenge, as there are lots of features
> that have to be retained. And how to do some things like provide a
> good way to interface with the database isn't at all obvious.
>
> Also there is this proposed standard for Media Player DBus Interfaces:
> http://wiki.xmms2.xmms.se/index.php/Media_Player_Interfaces
>
> Might use it as a starting point. Having "MPRIS" compatibility would be
> nice.
>
> Ian Monroe
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/amarok/attachments/20070815/ee85f529/attachment.sig>