What I was proposing was a VRML specific compression algorithm
Since we know what all the commands are, we can achieve very high
compression, and very fast compression just by mapping the commands to 1 or
2 byte sequences ...basically just making the file a binary file instead
of an ascii file and making the commands enumerated data types
To parse it'd be something like get byte # 123 that stands for some command
that requires 6 bytes of parameters following it, so grab the next 6 bytes
dump them into the command and read the next byte as a command...
We really don't need much flexibility, we can make the compression
algorithm optimal to our specific aplication...
Perhaps two byes for each command.. that would give us capability for about
65,025 commands... plenty.. and we could still expand beyond that by saying
say that #200 #200 stands for a new command set and remaps all of the
commands until we get #200 #201 which goes back to the previous command set
and two bytes for each command also allows for a little organization,
let the first byte of the command stand for the type of command...
say #1 is html, #2 is lighting, etc...
These are just a few musings....
-Nathan