[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Forks Tangent (was RE: [ProgSoc] jpg file)
On Mon, Mar 16 1998, Matthew Estela wrote:
| Anand Kumria [SMTP:wildfire@nospam.progsoc.uts.edu.au] wrote:
| > Why bother? If it is plain text then you can simply clearsign the data
| > (it'll have --- BEGIN PGP gunk like this message) if it is binary simply
| > do a binary signature. It'll force people to verify your signature.
|
| Well the gauntlet's been laid down. The first person to think of a decent
| use of streams that gets Anand's respect will probably get a nice cushy job
| with microsoft doing PR. Anyone that chooses to forfeit that prize can swap
| it for a beer.
Before I begin, it's best to point out that for any argument that can be
made for forks/streams, Anand will be able to come up with a
counter-argument, because the fact is that anything that can be done
with multiple forks/streams, can be done with a single one.
The question is whether to try a new concept for the sake of improving
elegance or reducing complexity, when there is a functionally equivalent
existing concept. There is a big precedent with applying the question to
programming. Common examples: any program that uses a two-dimensional
array can be re-written with a one-dimensional array; any
object-oriented design can be implemented in C with stucts and function
pointers; any program written in Eiffel can be re-written in C, or even
80x86 assembly language. Historically, the right answer has often been
to go for the new concept, but only after it has been researched
thoroughly enough to get a good understanding of its pros and cons.
Whether this is so for multple file forks/streams, I don't know.
Anyway, to the example of interesting use of forks. One of the problems
encountered with HTTP servers is where to store meta-information for the
files they serve. HTTP responses consist of 2 parts: a header, and a
body. The body consists of the data content, while the header contains a
response code, information about the server, and file meta-data.
Meta-data describes data: it can include things such as the date the
data was last modified, the MIME type, the number of bytes, the expiry
date, etc. Some of this information can be stored within the file's
entry in the filesystem, such as the size and last-modified date, but
other meta-data is specific to HTTP.
With NCSA and Apache, extra meta-data can be stored in either global or
per-directory configuration files. This is messy, and makes it hard to
maintain the meta-data to be consistant with the data. Another option is
having a .meta file for each data file, which is better than the
config-file approach, but the chances of the meta-data getting out of
sync with the data is still pretty high.
Now, if your filesystem supports streams or forks, then it could store
the file data and meta-data in two seperate streams. And, if the
filesystem had a standard way to encode NAME-VALUE pairs inside streams
(I believe MacOS resource forks uses a standard NAME-VALUE format), then
you could use standard OS tools to manipulate the meta-data.
That should give you some food for thought.
Cheers,
--
Dennis Clark dbugger@nospam.progsoc.uts.edu.au PGP/MIME spoken here
-------------------------------------------------------------------------------
/* we have tried to make this normal case as abnormal as possible */
--Larry Wall in cmd.c from the perl source code
--
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.
This list is archived at <http://www.progsoc.uts.edu.au/lists/progsoc/>