scripting API

[Ian Monroe]

Mark, Peter and I came to a consensus regarding the scripting API.
This email is to let everyone else know what's going on and to make
sure that we actually do have a consensus.

A few conclusions:
*QtScript is awesome. Using some technology from QtJambi (
http://labs.trolltech.com/page/Projects/QtScript/Generator ) it can be
given access to all of the Qt api. The Qt api should provide access to
let script writers do most anything they want. And even Mark admits
that despite not being Ruby, JavaScript is not-bad.
*External scripts can result in confusing dependency hell (how many
times have you seen questions about getting some script to work in
#amarok). So they are less-the-awesome.
*It would be a bit confusing to have the script manager have a
separation between internal and external scripts, especially for the
script writers. KISS.

Peter has already implemented the MPRIS DBus spec. This provides basic
playlist manipulation and querying what is currently playing. So our
idea is that would be pretty much all that would be done in DBus. The
Script Manager would not launch external scripts like it does in
Amarok 1.4. Any additional DBus api would be to ensure required
communication with some specific external application: eg KRunner.

Instead the entire focus would be on in-process scripts using the
QtScript framework. My main concern about in-process scripts is their
ability to lockup Amarok itself. Hopefully we could alleviate this
issue with utility functions for doing stuff like downloading web
pages in a safe way. So my attitude now is that having full
out-of-process script support is trying to solve a problem (scripts
locking up) that we don't know will actually exist.

A good example of this is Firefox extensions. They are also written in
JavaScript, are wildly successful, work most of the time, but do have
the ability to mess things up. So we should be careful, but not
totally afraid of in-process scripts.

So basically Peter's modified GSoC goals are to now:
*DBus MPRIS implementation (he is done with this mostly)

*Have the Script Manager run QtScript's.
**Using the binding generator, QtScripts will have access to the Qt
api. (Perhaps some parts of the kdelibs API, eg Solid, if there's a
reason.)
**These QtScript will be given access to Amarok via new classes that
wrap up calls to various functions. (So that our scripts will have a
stable api).
**Utility functions and examples to make it easy for script writers.
**QtScript should be able to do everything that DBus/DCOP can (lyrics,
service framework), plus other cool things.

*Write a mass-tagging gui using the QtScript framework, to put the
scripting framework through its paces.

Ian
P.S. If other GSoC students think they're requirements have changed
just write the list. Software requirements changing are part of
software. Eg. in Peter's cause he has "clients" (Mark and me) that
keep changing their mind. :P