• Remember to update ToDo before release!
• Make sure wf_mapname and wf_basename work in the network version.
• At some time, trawl through all source and prefix *all* local functions with static. This has been up before, but did I remember? Noooo.
• 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.

• Check locking issues. I just spotted one in make_item (wf-engine.c).
• 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*.]
• Fix some sort of cache/hint mechanism for make_prefix()!