Re[2]: Web Server & Documents

["Walker, Arlen P" <Arlen -dot- P -dot- Walker -at- JCI -dot- COM>]

Arlen P Walker
04/10/97 09:22 AM




        o You've got massive amounts of disk
        o You can create 2 byte files without confusing the FAT

Neither of these points really applies. Until a recent server upgrade, I
had more disk on (actually under) my desk than the departmental server had.
(It's a long story, but it was mainly because I did the presentation
graphics work, so I needed massive space for the images.)

As for the second, sorry, but even Unix doesn't allocate file space in 2
byte increments. (There's a difference between space allocated and space
used. If space has been allocated but not used it is wasted, unavailable
for anything else to use. Our HP PA-RISC stations have a blocksize of 512
bytes, for example.) Despite the impression they'd like to give, MS didn't
invent the concept of a FAT. It's simply an implementation of a concept
that has been around as long as the first disc drive. Every OS uses a
mechanism to allocate sectors (some OSes call them "blocks") on a disc and
keep track of which sectors have been allocated and which are free (and
this is done at the sector level, not the byte level). MS is just the only
OS vendor that rubs your nose in it; most of the other vendors manage to do
this much more transparently.

      Precisely.  I may or may not run UNIX, but I'm certainly going
      to choose a computer with lots of disk as my server.  Hopefully, I'll
      find an OS that doesn't get confused with 1/2 Kbyte files.

We're not talking about confusion here. All OSes know how many bytes are
allocated to a file, and how many bytes are actually used by that file. The
fact that these two numbers are not identical isn't confusion, it's simply
a matter of efficiency. It's more efficient for a disk drive to begin
reading at the start of a sector (and drives had sectors long before
desktop machines were created). Space is utilized more efficiently if files
are allowed to begin anywhere on a disk. And the more sectors you have on a
disc, the more space will have to be devoted to managing their allocation
and taken away from potential users. The art of I/O design is to arrive at
an optimum tradeoff among these factors, by jugglng the size of sectors and
minimum allocation units. The system isn't confused by putting lots of
small files on a disc. It simply is inefficient at storing them.

      I'm not sure about this, but releasing docs via CD looks like a
      different issue from releasing a document via Web server (see subject
      header). The question seems to be how we would put documents on the
      net.  Not customers.

There's where I got confused, then. I thought the question was about
issuing HTML docs that the *customer* would put on either a local disc or
intranet server. In which case it's part of our responsibility to deliver
files which make that easier (or at least not make it harder) and to come
up with some sort of warning about what resources it will require, even if
it's just "These docs will eat your disk for lunch and still ask for
more!".

      But again, the topic seems to be how TWs should handle this issue.
      Not our customers.  There's no reason to assume we're stuck with a
      Microsoft OS as the server.

But, the world being what it is, there's also no reason to assume we're
not.


Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 224

Arlen -dot- P -dot- Walker -at- JCI -dot- Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html