
In no particular order:

 * Clean out all the old junk from this file.
 * Split out daemon
 * Create expanded files
 * Add index to compressed files (and to partitions eventually)
 * Automatic backup
 * CGI to display public
 * CGI for private data
 * Separate given names and family names
 * Fix disc lists to deal with at least one level of subdirectories
 * Add --link option to disc_list
 * Create a program to check all objects read ok
 * Split files into specific types (have a different class for jpeg, etc)
 * Move public data to the server (instead of a file).
 * After public data is on the server, automatically submit data from user.
 * Add to log_disc a print of existing copies and where they are located.
 * Fix to add public md5sums for public isos and structure to have them on
   private backup discs.
 * Find out how to configure a debug build using Autoconf (if possible).
 * Fix export_file so older revisions of a file can be exported.
 * Fix diff_compressed to deal with removed blocks (assume in order now).
 * Fix patch_compressed to deal with removed blocks.

 * prep_disk on drive spits out: "after last write: Invalid argument" at
   the end.

 * Fix all or most of the "exit(x)" calls to call "nwos_exit_objectify"
   instead.  Pass a string to be logged along with the exit code?

 * Need to fix the big_bang to create all dates starting in Oct 15, 1582.
   No, this would create too many unnecessary dates (although it would be
   cool to have them all).  For now just create every year from 1582 on.

 * The 'nwos_read_class_definition' function in class_definition.c is NOT
   setup to read the feature_definitions into the object.  This is because
   none of the places it is called can cope with a variable sized class
   definition.  THIS NEEDS TO BE FIXED!!

 * The existing multiple file name and file associations isn't going to work
   because a disc_list can't just point to a file path or a file it has to
   point to a specific association of the two.  Going to have to go with the
   file association object as described on page 100 of my notes (5-Nov-2006).

 * The new plan (27-Nov-2006): have the most significant bit of the flags
   (byte 0 of each block) indicate if the block is encrypted or not (1 means
   not, to be compatible with existing objects).  Abandon the idea of using 
   the upper nibble (0) for public/private.  Objects can once again use the 
   whole range of values.  Need to write a program than can convert encryped
   files to unencrypted.

 * Have a separate partition that is unencrypted for music etc.

 * Change all malloc's to nwos_malloc (fix above reference list first).

 * When reading files, process several files at once, and queue up the disk
   reads and read across the disk in order.

 * Perhaps I should go back to longer id's if there is a fixed range of system
   and public objects.  Don't want to repeat the Y2K fiasco!  One more byte
   should be enough, but 5 bytes is so uneven.  I'm sure six would be enough.
   If we just used the ones with the upper byte zero that would be more than
   a trillion public objects.  If we used everything that had the upper
   nibble zero, it would be 16 trillion, leaving 240 trillion for non-public
   uses.

 * If all of the base objects are predefined, then the chicken and egg problem
   goes away and you can create objects individually.

 * The new plan:

    1) Get back to a working version (big_bang_06).
    2) Use the new directory naming convention, but stick with 16 byte refs.
    3) Change the classes so that the first run of "big bang" generates the
       class definitions (at least the attributes).
    4) Reverse the process and regenerate the classes from what is stored in
       the real class definitions.
    5) Still need to figure out the "thing" thing.

 * The "class" of an object stored may need to change depending upon it's
   context.  For example in a "thing" where it has different names you don't
   care if it is a noun or a verb, but you do care what language it is:
   English, German, etc.  Another example would be inside of a word it doesn't
   matter if it is a vowel or a consonant, it just matters if it is a letter.

 * Change to have one level of indirection, for all fixed objects.  I.E.
   once a US state has an identifier, it is always that identifier and then
   it points to the current object.  OR perhaps for objects like this it
   just should always stay the same object and we always add stuff to it?

 * Could add a "resolved" flag and not load everything while resolving
   other objects???

 * Change object_grade to source, to describe the source of the object.

 * Need to have a warning system in place, that can send a message to users
   say in the case of a security problem found in the operating system they
   are using.

 * Need to move the code into objectify itself as well.  The plan for this
   next version was to generate C structures from the objects.  I am
   wondering if the C code should be generated from the objects as well.
   That way we could at some point generate code for various languages such
   as Java, Eiffel, Ruby, etc.  This of course creates yet another chicken
   and egg problem.

 * Convert from the Alpha_04/Alpha_05 format to the "new" format.  The object
   reference size goes from 4 bytes to 16 bytes.  Characters in spelling
   objects go from binary characters (ASCII) to letter objects.  This means
   the whole character set structure needs to be created.  Need to add the
   actual object layout to the class definition.

   My first attempt at this "convert_to_new_format.c" has gotten unwieldy.
   Perhaps it would be better to just create the base objects from scratch
   and then "import" the old format objects into it??

   Unfortunately, we are then back at the same chicken and egg problem: the
   class definitions need to have all of the language, words, spelling and
   now character structures in place.

   Here's a thought: make a transitional version of the "big_bang", that just
   generates the absolute minimum set of "new" objects.  The class definition
   class.  The feature list, name, word, spelling, letter, character set, etc.
   classes.  And then all the objects to completely implement all of those
   classes.

   Have a transitional version (between Alpha_05 and Alpha_06) that is all of
   the code that converts from one version to another.  Then remove all of
   those programs that were just for the conversion (they could still be
   obtained from CVS).  Then have an importer for the old Alpha_04/Alpha_05 
   objects.

 * Is it time to make a daemon for objectify?

 * The server could hand out blocks of 256 to each machine to use for public
   objects.

 * A whole new idea: instead of having reference lists, every object just has
   attributes that cross reference each other.  Complex objects are no longer 
   a fixed format.

 * Add a signature to each object so that if the object is changed it no
   longer has the same signature.  Actually an object can't be changed, but
   if a new object is created it will have a differenct signature.

 * New plan: have the 4 (or however many) base objects stored as text files in
   the distribution.  Those 4 objects can then be converted to binary by the
   big bang.  Then the remaining classes can be generated from some sort of
   class source format file?

 * Get rid of log.txt, it is a possible security hole.

 * Probably should eliminate the one security fits all objects idea.  With only
   one level of security and there is a breech, you're screwed.  For example
   if you had one level of security on a laptop, and you were running Firefox
   (a version integrated with Objectify) they would have access to everything.
   This would be bad!

 * The above brings me back to the question of whether public  objects should
   be encrypted?  It would certainly simplify system start up, if a base set
   of objects weren't, because you wouldn't have to have a key to get things
   going.

 * Add encryption of reference lists.

 * Eventually we need to get to the point where objects just exist and are part
   of the intall, instead of trying to create them all in the "big_bang").

 * Put actual class data layout in class instead of just the object size.

 * Split up reference list by class type it is pointed to (I.E. the first level
   of a reference list is an index into different reference lists for each type
   of object it is pointing to).  But what do we do about inherited classes?
   Take phone for instance, are there 3 reference lists, one for each of home,
   work, and mobile phones, or just one for phones?  I would say just one for
   phones.

 * Add one level of indirection to the object references, I.E. an object
   reference points to an object that points to the actual object, includes the
   location of the actual object data, and the MD5 (or SHA256 whatever) of the
   object.

 * Versioning of objects.

 * Make storage in spelling objects always lower case and then adjust
   accordingly in higher level objects.

 * Fix words so there isn't a one to one with things, because as we all know
   from "Stairway to Heaven" words can have two meanings :)

 * Add toll free area codes (800, 866, etc.) and pay codes (900, etc.).

