I think Gavin's post earlier today, describing how he would create a
VRML file of the entire planet, seems to suggest that too much of a
fuss is being made over compression.
What is wrong with waiting for the deployment of VRML files before we
argue how to best compress them (*if* we decide we need this). I'd
rather wait on this topic, rather then deciding next year at this time
that last year we were too hasty.
I think (in general) the public would rather compress files in the
future, rather than having to go back and uncompress files they've
been creating the past year.
2) Tokenizing. I'm really surprised to see that this has popped up now.
I remember when I first started to look at VRML I thought to myself
"WOW! you need a large number of look-ahead-characters in order to be
able to parse VRML". I am surprised at this because I think it shows
the number of people who are approaching this at the angle of "okay,
how do we start implementing all of these groovy ideas" from the
people who are thinking the groovy ideas. At some point these two
groups are going to have to meet, otherwise this is going to become
a *very* unfriendly list -- I predict battle scars before 2.0 sees
the light of day;-)
I am not *terrible* as against looking at tokenization of VRML at
this point as I am compression of VRML files. If someone wants to
see tokenization of VRML they should make it happen (with real live
PD useable code) before we discuss it. If **real** code emerges I
bet it happens....anyone want it this badly?
3) Both compression and tokenization of VRML came about because people
don't want to see 1meg VRML files fly across the net, the people on
the end of a SLIP link are going to suffer. So lots and lots of charts
have been made that show how well VRML might compress under various
criteria. It wasn't until tonight that something struck me as odd
about those charts. Here are some questions in this regard:
a) a 1 meg VRML file is roughly the same as the average HTML page,
about 3 gifs is the average on an HTML page, and equal about 1 meg.
How many people suffer through HTML pages over SLIP? lots - with
inline images on?
b) do most SLIP users turn on compression, ALWAYS, NEVER or AUTOMATIC?
c) if a user's modem is already compressing data, and you send a
precompressed VRML file to him, and then he needs to uncompress it
by his parser, does that take longer or less time than if the user
was using modem compression, got a uncompressed VRML file, and did
not have to ask his parser to uncompress it? How much time is wasted
by the modem trying to figure out that it can't compress the
compressed file? Is that a factor?
d) how does question c differ is the user is not using modem compression?
e) based on the results of question b what do the results of questions
c and d really mean?
Knowing how files compress is step 1, what it means to transfer the
files to users is step 2.
--------------------------------------------------------------------------------
Neophytos Iacovou Distributed Computing Services
University of Minnesota 100 Union St. SE
email: [email protected] Minneapolis, MN 55455 USA