[Feedback] DBus Interface Needed Enhancements

[Miguel Angel Alvarez]

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.

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.

The database could see some small improvements: some simplified query 
mechanism, some way to add fields to save plugins related information...

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?

As a final suggestion, may be we should start a wiki page about this?

El Domingo, 5 de Agosto de 2007 09:34, Mark Kretschmann escribió:
> On 8/4/07, slaout at linux62.org <slaout at linux62.org> wrote:
> > Sébastien Laoût sent a message using the contact form at
> > http://amarok.kde.org/en/contact.
> >
> > While doing this program, I perceived some frustration in regard to the
> > Amarok DCop API.
> > I'm not mailing to complain, but to make constructive criticisms, and a
> > proposal for a better DBus interface in Amarok 2, so that all new Amarok
> > scripts and extensions can come to life, extending the Amarok user base,
> > and making them happier.
>
> [...]
>
> Thanks for sharing your proposal, Sébastien. This kind of feedback
> directly from an extension developer is very valuable for us.
>
> As far as I can see all of your requests make sense. I think we will
> try to implement them, step by step. One thing that I have been
> wondering is whether we should try to keep compatibility with the old
> interface - currently it's exactly the same as in 1.4, except that
> it's a D-Bus call instead of DCOP - or if we should make a new start
> and clean up the interface, remove inconsistencies and so on.
>
> Currently I tend to prefer the former solution, as for one it's less
> work, and second it makes it possible to port existing scripts very
> easily. What do you think?

-- 
Don't see the world through a window, be open{source}minded, and be free :-)