scripting proposal draft 3

[Peter Zhou]

thanks for your sharing and feedback!

On Sat, Mar 22, 2008 at 7:05 AM, Miguel Angel Alvarez <maacruz at gmail.com>
wrote:

> >Hi Peter,
> >I'd like to add my little grain of sand (I'm the replaygain script's
> writer)
>
> >More than just some UI signals, the scripts should be notified of any
> event
>
>that changes amarok's state or behaviour, so they can replicate accurately
> >the amarok's state. Currently, the number of signals is very lacking: no
> >signals on configuration changes, collection changes, device changes,
> play
> >mode changes, user initiated song changes, ....
> >To keep track on those changes, scripts need to continuously poll amarok
> >through dcop calls, which, needless to say, is very expensive


Yes, this is awsome! I should check and add signals which represent the
current Amarok state.

>
> >Don't know what to say about that.... does it refer to amarok's internals
> or
> >is it an API?
>

I am proposed to add some functionality by adding some classes and functions
in the dbus interface classes(Amarok2 will no longer use DCOP). And the
class I am going to add is classified by different usages or objects. It
seems it is confusing to use "API" here. The script may access Amarok using
DCOP/DBus/Kross fucntions, that is pretty much alike using APIs.


>
> >DON'T!
> >You shoundn't enforce any particular or personal preferences about
> scripts.
> >Let the script writers deal with that. If someone want's to go binary, it
> is
> >his election.
> >The issue of dependencies is very complex, and distribution dependant.
> There
> >is no safe way to deal with all of them, so I also think that the script
> >writer should deal with it. What you could provide, is some way to
> register
> >the executable (even different executables depending on plataform) with
> >amarok. Right now amarok just picks anything executable under the scripts
> >directory, which is not the best strategy.


This is hard. Different persons is holding different views on this one. But
this is only the matter of changing just several lines of code.
I know the dependencies is very complex, especially Amarok2 will be used in
different platforms. What I am exactly doing now is to register the
executable. But I also do believe my approach could provide a easier way to
both the writers and users. At least something is better then nothing. I
think it is necessary to check if a user has a database (not only installed,
but also Amarok recognized) before running a database related script.


> >About the number and quality of actual dcop functions, I personally find
> them
> >good enough, so they are a good starting point.
> >Just a note, the comunication between amarok and the scripts needs to be
> >faster. Actually some dcop calls may take several tenths of second to
> return,
> >causing very noticeable lags (which in my particular case, are very
> >important)


I am not sure of the efficiency of D-Bus. This could be the tradeoff of
using external DBus instead of internal Kross interface since the
in-proccess script failure may fail the entire program.
This should worth further discussion in order to find the balance of using
internal Kross and external DBus. (Maybe use more "safe" kross functions to
improve the efficiency.)

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20080322/74e2eda6/attachment.html>