diff doc/TODO @ 4778:dde7262d0a35

Moved HACKING and TODO under doc/.

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/TODO	Mon Sep 22 20:14:12 2008 +0300
@@ -0,0 +1,129 @@
+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...
+
+    
\ No newline at end of file