

package TODO
* more documentation (client manpages, basic api, etc.)
* allow installer to detect python location
	it is a possibility to have special installers for non-unix platforms

msn client TODO
* be able to use nick with spaces
	this can cause a lot of damage, is it worthy?
* full-featured tab completion
* line editing

msn lib TODO
* blocked and allowed lists
	this isn't hard and it might be handy for some people


Future / In doubt
-----------------
(things listed here are either marked to do in some future (because we have to
wait on some feature being popular) or are in doubt of ever being implemented
at all)

msn client
* signal handling
	when the signal module becames popular on distros, we can get rid of
	the select() ugly stuff for auto-away and re-implement it using
	alarm() or things like that; add support for SIGWINCH, send syncs
	often, etc.
* create a detached client with a server/client model
	this can be either a one-pc-only detached mode or maybe some kind of
	web interface; after all it should have very much in common, and with
	a couple of cookie handling and a browser which supports auto-refresh,
	a piece of cake (and java-free)
* make colors configurable
	either as colors or as random strings, so you can, for instance,
	output in html. this is here just because it's really low priority


msn lib 
* higher level callbacks
	I'm not that sure about this one.. it would be really nice to have ALL
	the protocol encapsulated and then call upper-level callbacks if the
	user just don't want to care about, for instance, message parsing.
	But, OTOH, maybe it's not worthy.
* make login async (maybe using something like continuations?)
	continuations would have worked nicely, but are only available in
	python >= 2.2 (which many people don't have), so it will have to wait
	for a bit
* group support (part is in place (eg. gid))
	do we really want this? If not, drop partial support
* multi-user chat handling 
 	part in place, the ugly sb.emails[0]
	is this useful? If not, drop partial support
* file transfer
	this is waaaaay below in my priority lists. there are thousand of
	better ways to do file transfer between two hosts; plus the protocol
	is even more ugly than the messaging one (yes, it really is)
* micq integration
	in a perfect world, this wouldn't even exist and we would have micq
	talk the msn protocol. so the ideal solution would be to rewrite all
	this in C and integrate it with micq; probably working in two
	different levels: one would be the C implementation of this, and the
	other one micq multiprotocol support, that allows a clean integration
	with it

