== Notes regarding xmms2-0.1DR1 ==

### not do myself ###
Suggestion in "src/xmms/medialib.c":
    mlib_add and xmms_medialib_add_entry and should return the ID of the
    medialib entry that was added.  Without this, a client has to query the
    medialib to find the ID of the song that the client just added.  This is
    annoying.

Suggestion:
    Allow clients to add multiple songs to the playlist with a single IPC
    function call. This should result in a somewhat saner outcome when several
    clients are adding large numbers of songs to the playlist concurrently. It
    should also vastly reduce the number of XMMS_PLAYLIST_CHANGED_MSGs that
    need to be sent.

Suggestion:
    Add a "consume" playlist mode which removes songs from the playlist as they
    are played. The consumed songs should be kept in memory somewhere so that
    going to a previous song will remain possible. This sort of operation could
    be simulated entirely on the client side, and maybe it would be better done
    that way.

Suggestion:
    Add a "no advance" playlist mode in which the next song is not played when
    the current song finishes.

Bug in doxygen comments and Web site wiki:
    The documentation is riddled with mistakes in spelling, grammar, and
    punctuation. It's also incomplete.


### do myself ###
Bug in "src/clients/lib/python/xmmsclient.pyx": *done*
    There's no facility for interpreting the return value of
    XMMS.playback_status().  Some constants analogous to the
    xmms_output_status_t enum are necessary.

Bug in "src/clients/lib/python/xmmsclient.pyx": *done*
    References to XMMS_OBJECT_CMD_ARG_HASHTABLE and XMMS_OBJECT_CMD_ARG_HASHLIST
    need to be changed to XMMS_OBJECT_CMD_ARG_DICT and
    XMMS_OBJECT_CMD_ARG_DICTLIST.

Suggestion in "src/clients/lib/python/xmmsclient.pyx": *done*
    Similarly, other references to "hash" and "hashtable" should probably be
    changed to talk about "dict" instead (for reasons of stylistic consistency
    rather than functional correctness).

Suggestion in "src/clients/lib/python/xmmsclient.pyx": *done*
    A get_type() method should be exposed by the XMMSResult class.  Appropriate
    constants should be defined for use with the return value of this method
    (i.e. XMMS_OBJECT_CMD_ARG_*).

Suggestion in "src/clients/lib/python/xmmsclient.pyx": *done*
    Using the XMMS class could be much more Pythonic when used synchronously.
    The user would never have to see an XMMSResult object.  Instead of having
    to call res.iserror(), an exception would be thrown.  Instead of having to
    call res.value() or one of the get_* methods, the result's value would
    simply be returned directly.

Bug in "src/clients/lib/python/xmms_client.py":
    Just about every call to the XMMS client API is broken and needs to be
    updated. CamelCase function names need to be converted to
    underscore_separated. Accessor methods for result objects need to have
    "get_" prepended to their names.

Suggestion in "src/clients/lib/python/xmmsclient.pyx":
    The documentation is rather poor.  Return types for most XMMS methods are
    usually just XMMSResult, which is accurate, but not very useful.  The
    expected type of the XMMSResult must also be stated.  Additionally,
    parameters for methods are completely unmentioned, which is extremely
    frustrating.  The number, positions, names, and types of all paramters must
    be mentioned.