eds todo list 2.2.4 - 2.5

Todo List as of today	(the order is important for some things)
This is not a wishlist, this is stuff I will be doing.

To put this in perspective, at the speed things happen in zinf this list 
probably easily spans over a year, but the majority of that is at the end.

2.2.4/5
.	merge fixes to pipeline to fix all deadlocks dealing with it.
.	merge fixes to our halfassed delete/free's that dont break zinf
.	Figure out why fixing some deletes/free's we break zinf and fix
.	get volume fixes merged (committed that is)
.	get new lock merged (committed only after pipeline/delete fixes)

.	Make locks for plugins at the lowest level inherited non-virtual 
functions exist for it. Use these locks for all methods.  Locks then 
will only be created by the top end object if it requires more than one 
lock.  The one lock created at the bottom level is to be the main lock, 
the lock that is enabled/disabled from outside the plugin and within 
when called.  This is to minimize deadlocks and corruption caused by 
having methods below our top end method that alter data that our top end 
object uses but no lock was wrapped around the low end method because it 
was called from outside one of the top end's methods.  (this could 
happen, not sure if it does often).  This should make things safer and 
more uniform since all methods off one of these bottom most inherited 
methods will have the same lock name.


.	help fix remaining bugs.
.	write skeleton plugin files to outline required plugin interface and 
design (if plugin is to be included with zinf).



2.3.x
.	zinfvolume becomes member function of physicalmediaoutput.  Our output 
plugin then has conditionals at the get/set volume methods to check if 
we're using cooperative volume, setting a boolean flag and if it is it 
calls it's inherited pmo object's respective method which is the 
zinfvolume method.  The boolean flag is used for the zinfvolumize 
function instead of the slightly more time consuming pref call. This 
will have a few other nice sideeffects such as not having to touch 
outside code to have an audio output plugin without mixer controls of 
it's own.  not to mention being cleaner and more logical.

.	preferences become some form of vectored strings. Plugins gain two new 
methods. One is to retrieve prefrence variable names and identification 
info and the other is to retrieve default values and respective variable 
name.  Upon bootloading, zinf queries all plugins found in it's plugin 
dirs, ignoring duplicates, and asks what variable names it supports 
before starting anysubsystem. This returns a mapped vectored list of 
strings. zinf sends this to a new method in the prefs class that adds 
this to it's current list of variable names. Zinf then calls the default 
values method of that plugin. This gets sent to the pref class via a new 
method.  So now the pref class maintains two mapped vectors of strings. 
  once all the plugins have been scanned in the plugin dirs it has, it 
asks the pref class to reread the preference file, the pref class then 
works like it does currently and puts in defaults for any not found 
ignoring any it doesn't understand or have in it's current list.  New 
plugins added to zinf wont be recognized unless you restart zinf (this 
is reasonable).  Zinf then can work like it normally does with no 
changes to any other code.

.	The preference changes power of course is to let us change how the 
other code works because now we have much more flexibility.  Once done, 
redoing the options pane in the gtk ui is key to taking advantage of the 
plugin's settings and unlimited nature of the preference class.  Making 
other aspects of zinf able to determine if a plugin is loaded (which it 
would be able to do now) will be really cool to get done. Zinf will then 
be able to really live up to it's "extendible" description.

.	port xing's equalizer code to be incorporporated into the 
physicalmediaoutput class much like zinfvolume will be.  it should 
require little work to do this.  it's even got ASM code if we are 
building with nasm support.  All output plugins then will have the 
ability to use the equalizer / software volume by simply adding a 
conditional before writing data to their respective audio device api and 
executing the method by calling their pmo object directly.

.	if nobody has fixed the http code stuff by now, start doing that.

.	look into figuring out exactly which object is using the assload of 
ram that zinf uses.  If it's in the bitmap stuff, cry and wait until 
2.4. otherwise fix damn problem.


2.4.x
.	if assload of ram usage is the bitmap code, create gtk2 ui that uses 
no themes, stealing as much code from old gtk ui as possible dealing 
with the musicbrowser and such.  I want to use gtk2 in preparation for 
this ui to supercede the old one come 2.5


2.5
.	serialize pipeline.  (this may need to be done before if it is 
determined that we cant fix certain bugs without doing it.

	



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en