
This is part of the Objectify project documentation.
Copyright (C) 2005, 2006   J. Scott Edwards
See the file README for copying conditions.


NOTE:

  For Alpha_10 I Combined this HISTORY file into RELEASE_NOTES, 
  too hard dealing with two files and why use two when one will 
  do?


Alpha_09 - 04-Feb-2006

  This release was never actually created (Not tagged in CVS).  I
  did create a few objects with the header version 0009 and then
  decided to change the header format yet again.  So I decided to 
  increment the header version to 0010.

  The only CVS tag related to the files that created 0009 objects
  is "big_bang_03".


Alpha_08 - 02-Feb-2006

  This release was never actually created (Not tagged in CVS).  I
  did create a few objects with the header version 0008 and then
  decided to change the format again.  So I decided to increment
  the header version to 0009.

  The only CVS tag related to the files that created 0008 objects
  is "big_bang_02".


Alpha_07 - 30-Jan-2006

  Unreleased version - DO NOT USE

  This version is just a marker.  I created a base set of objects
  from the Fine (Eiffel) program create_base_letters.  But then once
  again decided to change the format before proceeding.

  This is the first version that uses Fine (Eiffel) for programming
  instead of C.


Alpha_06 - 23-Jan-2006

  Unreleased version - DO NOT USE

  This version is just a marker.  I created a few of the base objects
  but then decided that the header format needs to be changed before
  proceeding.

  This is the first version where the public objects are created once
  and they exist from that point on.  This version was the first
  attempt to create the base objects.


Alpha_05 - 09-Jan-2006

  Merged create_person (cperson), create_phone (cphone) and 
  find_phone (phone) apps into one app called "computer" that can
  do all of those things and more.

  Fixed several bugs in the name code, that mismatched names.

  Added cities and states now have capital cities.

  Changed "big_bang" to update objects from Alpha_04 (0004) objects
  to Alpha_05 (0005) objects.


Alpha_04 - 30-Dec-2005

  Added security by encrypting all of the data objects (but in this
  version reference lists are NOT encrypted).  The object's data is
  scrambled into 512 bytes of random data and the simplest form of 
  the Blowfish encryption is then run on the 512 bytes and it is
  written to disk.

  For now only one security option is available, all of the data is
  encrypted with the same key (pass phrase).  The pass phrase is a
  minimum of 34 characters.  If the pass phrase is lost or forgotten
  ALL DATA IS LOST as well.

  Changed the objects that have variable length data (Spelling, Name,
  and Year objects) to be a variable size.  This was to allow the
  random data to be better utilized.  I.E. if a spelling object for
  example was a fixed size (like before) and allowed a space for 100
  characters (like before) then 100 zeros would be in the random data
  and give some clue as to the data.  With the variable sized objects
  there are no zeros to be written into the random data and so there
  are fewer clues as to the contents of the data.

  Added disclaimers when the "big_bang" program is first run.


Alpha_03 - 29-Dec-2005 (Additional note added after Alpha_03 release)

  Also changed in Alpha_03 was the format of the version numbers.  In 
  Alpha_01 and Alpha_02 the version number in the file header was three 
  digits and was followed by a character indicating the endianess of the 
  object as it was stored on the disk ('l' = little endian, 'b' = big 
  endian, and 'n' no endianess).  In Alpha_03 the version was changed
  to be four digits and the endianess character was eliminated.  The
  endianess was eliminated because I decided to always just store and
  transfer objects as big endian and reversal needed (on little endian
  machines can be done when the object is read in from disk).

  So then the version numbers in the stored objects were:

    Alpha_01: 001x (where x is the endianess character)
    Alpha_02: 002x (where x is the endianess character)
    Alpha_03: 0003


Alpha_03 - 27-Dec-2005

  Changed the ObjRef again so that it is only 4 bytes instead of 8 bytes.
  The logic behind this is that even with a 250 gigabyte hard drive you
  can really only have a maximum of 488 million files since the size of
  each object is 512 bytes.  That is less than 12% of the available ids
  using 4 bytes, so there really isn't any danger of running out of ids
  right away.  A terrabyte drive would still use less than half of the
  available ids.  And when we start having 2 and up terabytes on a drive
  we should be fairly easily go to 5 byte ids.  That should be good up
  to a petabyte (is that what is after terabytes?).  There is no need to
  go from 4 bytes all the way to 8 bytes because there is no reason to
  have to be binary multiples since we are dealing with them one byte
  at a time.

  The object reference size should be adjusted to fit properly on the 
  storage medium, when 5 terabyte drives become available it will need 
  to be 5 bytes.  On smaller devices such a 256 Mb flash drives (assuming 
  minimum files size is still 512) could even do with 2 or 3 byte object 
  reference.  Let's see two bytes: 512 * 65536 = 33,554,432 would be good 
  for up to 32 Mb and three bytes: 512 * 16777216 = 8,589,934,592 would
  be good up to 8 Gb.

  Since we only have 4 bytes to deal with there is also no need to use
  the weird base32 file names.  The funny base32 filenames were kinda
  cool looking and made it easy to find objects, but that also made it
  easier for anyone trying to crack the system to get information.  So
  for security reasons I have changed it to use completely random ids.


Alpha_02 - 24-Dec-2005

  Fixed bugs in the create_phone and find_phone apps that couldn't deal with
  names where there was only one choice.

  Fixed bugs in the create_phone where the string buffers for area code and
  phone number were too short (not room for the new line character).

  Removed the "host" id from all object references (ObjRef).  Host redirection
  will be done with "redirection" objects in the future.


Alpha_01 - 22-Dec-2005

  I do NOT recommend using this version to store information that you don't want 
  anyone else to read.  There is no security in this version, all of the data 
  can be easily be read by anyone with access to the files.

  This is the first version that actually does something.  You can input 
  information about a person including their phone number and read it back.


