comparison doc/TODO @ 4778:dde7262d0a35

Moved HACKING and TODO under doc/.

4778:dde7262d0a35

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...