Resolved ToDo points are marked with a "-" and moved to the end.
Possibly solved ToDo points are marked with a "?" and left in place.

 * Remember to update ToDo before release!

 * There's a Potential Overflow in wf_client(servercomm) [NB: internal
   overflow only] in that a command to the server can't be more than
   MAXPATHLEN-1 characters long.
   
 * Man pages
  	Will Come. But not really soon, I don't think. Hmm. Idea!
	Write up something gobbling in c-comment-mode's function
  	comments and churn out a base man page to work from.

 * Full free-text docos
 	We have all public functions and almost-readable comments
 	finished. There is a "Document Of Intent" for the networking.

 * Possible problem?
	We use an int counter over in wf-engine.c(read_all_actions) that
	might (just might) lead to problems in large maps. This is not in the
	pipeline to fix, since we need at least 32767 actions to wrap
	around into error-indication. And if we have *that* many
	actions in a given map, we really should use something else,
	neh?

 * User-based permission/denial/list-of-items
 	This isn't really in the pipeline for the moment. It should be
 	done, at some point, otherwise Big Business no want to
 	play. Biggest problem, as I see it, is that two stuffs need to
 	be done.
	1) Implement "these users/groups have permissions to list a
	   given action".
	2) Implement access restrictions on individual actions.

	Both should take some sort of ACL (to be maximally flexible)
	and one shouldn't be allowed to touch an item that only
	resides in actions we don't know about. Ideally, we shouldn't
	even know they exist, but that is for an even laterer date.

Resolved issues(?):
 - Locking bug in move(). Locking bug confirmed. Commencing cleansing.

 - In wf-engine(move), we have a few potential trouble spots. It wreaks
   potential havok with running multiple local wfclients. Ah,
   well. That's for the test suite to figure out...

   Seems as if we were wrong. The problem was in reading up items from
   persistent storage (read_item()).
   
 - And there's a possible SourceOfBugs in
   wf-engine(read_all_actions). Memo to self: FIX!
   
 - Say, would be nice if we loaded up *all* items, neh? Do we???
   Nope.
   
 - Strange crash in my_accept() (seems to be memcpy()-connected).
   Cause *might* be related to network/no-network config. Couldn't
   provoke it again. It's probably a hallucination.
   
 - Add a generic "write to server" thing that returns the read Sexpr
   from the server and accepts printf() format strings, should
   implement "sane" error handling...
   
 - Seems as if a good non-blocking readed was a bit tougher than I
   thought... Ah, well. Nothing like a challenge, is there?
   Hmm... This would be much much easier if I actually *had*
   continuations... Scary, a place where scheme weirdness fits in.

 - Network protocol
	Network control is being worked at. Biggest problem at the
	moment is a sane implementation of the client library. in the
	pipeline are *two* client libraries and one server. Library #1
	is a network clone of wflib.a (wfnet.a???), the other is,
	basically, a network implementation of wfshell.

	There is some sort of ideological issue, here. What happens if
	we get network errors while speaking to the client from the
	server. The current methodology is to simply *drop* the
	connexion from the server end and mark it as "unused". Wonders
	how weird that'll become in reality. Look into this, at a
	later date.
 - Shouldn't there be fuctions to get (a copy?) of playground and actionpath?
   That might come in handy when wanting to change one...

 - IMPORTANT! Make sure to write error-handlers for wf-server and
   wf-client!

 - Make sure Each And Every internal function is prefixed with
   "static"... That's caused one namespace collision, so far (eh? I
   thought that was SOP in C? Methinks I am confused, again)

 - There is a bug in c/s open_item(), check tonight, eh?

 - Test environment
	Test enironment stubs are there. There *is* the "playground/"
	map. But it really should be re-implemented as something
	making a bit more sense, with, perhaps, timed checks to see
	that locking works (it does, but can we be sure it'll work
	when we add more locking???) and that pre and post proggos
	actually work.

	Pre- and post exec works. Just tested. There is testlocal and
	testsys (NB testsys doesn't seem to work?)[it does, now]

 - Testsys work:
   Write something to stuff and retrieve item data! Preferrably a dedicated
   program (at first). There's *something* fishy in there.

 - There's a weirdness somewhere in either wf-engine or wf-server, in
   that we can see a corruption in all_items. This is *bad*
	[this was a corruption, yes. But, strictly speaking, saving a
	 pointer to a string that is just about to be freed is *bad*.]

