view TODO @ 4661:e4e7999a21bc

Move D-Bus initialization before plugin system and playlist initialization. (The other changes in this changeset are to remedy the problem arising from the move, which resulted in annoying pause during startup due to D-Bus being initialized when assumed not to be.)

Long-term "TODO"
================
- output plugins should have some kind of (optional) "query available formats"
  function, so that the core could determine what should be used. perhaps
  offer users this info?

- remove the idiotic XMMS compatibility output plugin hack.

- all audio plugins (input, output, effect) should be made completely
  re-entrant. this probably means severely breaking the API. not very
  trivial either :(
  * basically plugin init() should allocate / init a state struct to
    be used in all operations, etc.


- the equalizer should be fixed .. in more than one way:
  * equalizer was broken by asphyx's libSAD
  * lots of things are hardcoded, like number of EQ bands. this should
    be changed.


- URIs with "?" are stripped (the subtune support uses that), which is bad,
  because some (a lot) of real-world URLs use 'GET' arguments. this breaks
  probing, but current input probing is confusing (and possibly broken anyway)
  and should be refactored.


- mime-types support:
  * there is already code for mime support, but I think it may not be
    sufficient as it is designed for input plugins only -- 
    also playlist containers etc. need this (IMHO)

  * might be nicer to have the type registrations in plugin struct
    instead of a separate function, a'la vfs_extensions.


- document the different APIs via Doxygen


- unified debugging/message system, for core and plugins
  * something like glib logging system, with logging levels
  * hardcoded "debugging" levels and/or macro-wrappers that would
    disable superfluous debugging output compile-time.
  --- being planned by ccr


- audacious VFS is not 64-bit offset safe, breakage will most likely occur,
  if files larger than 2^31 are used (rather unlikely, tho, but still...)

  * nenolod says: current vfs sucks, it needs a "rewrite":
    - buffering support
    - non-blocking I/O support


- {core,plugins}/configure.ac need some cleanup loving.
  * make session management (SM) optional. (done)
  * build system cleanups .. extra.mk.in? wtf? (done in core, progressing
  for plugins)
  --- this is in progress, worked on by ccr


- plugin rewrites:
  * madplug
  * modplug (in progress by ccr)
  * scrobbler


Playlist code issues
====================
It's been determined that the playlist code should be completely refactored.

ATTENTION! Add more stuff here! Issues that you can think of, suggestions
for solutions, etc. References to algorithms...


- code (mostly in playlist.c) is unnecessarily complex in some places and
  there is lots of useless duplication.

- what data structures should be used? things that factor in are
  efficiency and scalability -  memory usage and speed.
  see also below and notice the manipulation bottleneck(s).

  (different structures typically have bottlenecks in different places.)

- playlist_clear() is VERY slow with large playlists, possible reasons?
  * GList scalability sucks? (it does, but is it the real reason here? need
  to profile this...)
  * maybe playlist_entry_free() is at fault instead? (see also below)
  * mowgli_heap_free()?

  possible solutions?
  * mempools for playlist data? not sure if possible, the tuple heaps
    should then somehow be collected into pools...
  * storing the playlist as a GtkTreeModel seems to be fairly fast (at least
    in mudkip-player it is) --nenolod

- current implementation has a nasty racecondition in scanner thread vs. playlist
  manipulation (playlist_clear(), free, etc.)

  * new code should be water-tight when it comes to locking. simpler code
  with more "atomic operations" should help.


ccr rants:
----------
I suggest that the whole playlist manipulation should be moved into separate
thread. What I mean, is that the playlist scanning (e.g. probing for
metadata) AND adding files into playlist should be in a thread.

Adding files would work like this:
  1) feed URIs to playlist handler thread
  2) playlist handler notices new URIs and starts checking if they are valid
     aka probing or other checks.
  3) valid files/URIs get added to the playlist. unsupported files get discarded.

Possible benefits of this approach:
  - checking for "can we play this?", which currently happens in main
     thread and blocks the GUI etc, would now happen asynchronously.
  - improved user experience: less blocking generally, and it would be even
     possible to _parallelize_ probing, if we wanted to, getting metadata
     for multiple files at the same time. (this could be a user-settable
     option.)

Bad sides:
  - requires careful design and thread locking .. but that we need anyway.
  - possibly might make playlist GUI representation harder. I am not sure
    what effects this might have, feel free to pitch in thoughts...