
To do
-----

    High priority

    - FSED is buggy as hell
    - File editor (to rename, change flags, etc)
    - Filearea on/off selector
    - ctrl-b Usered kicks out current user?
    - Upload time rewards may not always work?
    - Add ability for users to describe their uploads which 
      have no file_id.diz...

    Average priority

    - utils/tosser.c, utils/robowriter.c, utils/msgbaseopt.c and
      utils/fixbases.c do not update messagearea pointers?
    - "Ask Unvalidate"-option to Validate()
    - "Last visit" to every filearea, into users own datas
    - Lastcallers utility
    - better CTRL-C handling
    - Enhance newuser questionairre (modularity, more dynamic)
    - User finger command
    - All BBS text strings are not yet in "display/strings.???",
      some are still left hardcoded into the source.
    - localupload() has a slight memory leak
    - New style duplicate checking for protocols. Instead of the
      current style of providing a list of directories to make
	  a stat() in, the protocols should execute "dcheck <filename>"
	  for each file. Atleast adapting smodem requires smodem-
	  authors permission...

    Low priority (or Hard stuff) :) 

    - Doing "Selected conferences/messagebases" with linked lists seems
      inefficient. If someone can come up more efficient (and still dynamic)
      way of doing this, let me know.
    - Python module for easier door programming?
    - Better configprogram?
    - Ability to copy or link files from some area/conf to another,
      not just move them
    - CD-ROM browser door. It would let user access and download files
      from whatever disk appears to be mounted in some certain dir location.
      It should include "files.bbs" description support.
    - Multinode chat + smodem multinode chat
    - BlueWave (or OMEN?) offline reader support
    - Doing time-left checking BEFORE download is stupid, because the
      cps rates usually vary. Solution: Fork a separate download-process,
      send it a break signal if users timelimit is reached [main
      process could take catnaps with alarm()]. Dl-process can in turn 
      kill the external protocol.
    - Some kind of "Visual Data Editor" 'standard' would be nice. It could
      be used to give user or sysop an uniform way to edit the 
      user/file/area/conf/msg properties. Idea: Some program would create 
      datafile for VDE from C structures or MySQL tables, and VDE would
      show then ANSI screens with text/num/toggle fields/gadgets, 
      so you could go around it with cursorkeys and modify values...
	- Msg writing leaves "msgheader.<node>" to tmp/ dir ... 

    If you have some additional ideas, feel free to e-mail them
    to me. See the main document for address. 
    
    Also, if someone bothers to code some of the functions or doors
    mentioned above, I'd appreciate it. You'll naturally get your
    name highlighted in the hall of fame. =) 


Further VMatik development topics, open for discussion
------------------------------------------------------

Topic: security, crypted file transfers over the net

	See main document "docs/vmatik.doc".

Topic: Is a Bulletin Board System obsolete?

	Internet is the name of the game today, and not many bother 
	to call BBSes through phonelines anymore. BBSes can operate
	through the Net, but do people know how to use them, anymore?
	The lack of graphical interfaces is poison for the www-drugged
	masses. Will they bother to learn how to use a conventional
	BBS system? In many ways VMatik provides quite powerful way
	of file transferring compared to the typical ftp- or www-
	sites, which especially lack in the upload-, batch-xfer and
	criteria based file selection department. 

	Could or should VMatik be turned into a kind of www server
	or an add-on to an existing one? 
	
	It would seem quite fancy to be able to dress the cake with
	colourful graphics, while still maintaining all the nice
	stuff we currently have. But unfortunately many questions
	arise and after some thinking are left unanswered. They
	include
			
		- Security issues
		- File transfers, batch ul, batch dl
		- Text editors
		
	The current HTML standard doesn't seem flexible enough to 
	allow the kind of operations we'd need. And even if it would,
	the amount of work would be staggering. So vmatik will 
	continue as an ascii based effort.

	If mad enough, though, vmatik might be programmed to include
	support for it to function as a very complex "fserve", 
	a software used through IRC, using DCC for file transfers 
	and private messages to receive user commands and send
	text output.


