Good IF archival: Lessons from the xxx physics/math archives

2 views
Skip to first unread message

Greg Kuperberg

unread,
Oct 14, 1998, 3:00:00 AM10/14/98
to
As a very occassional reader of r.g.i-f, I would like to offer an outside
perspective on the task of archiving the world's free Interactive Fiction.
(I played Christminster and Reverberations and dabbled a little with
a few others, that's about it.) The IF archive is certainly much more
convenient than no IF archive, and it is good that it is complete. But
there is a great deal that it does not do. The IF community here, which
includes some highly competent and highly motivated software developers
and site administrators, could learn many lessons from the history
of the xxx archive system <http://xxx.lanl.gov/>. With over 80,000
freely available research articles, this system has had a major impact on
scholarly communication in physics.

If you want to evaluate xxx, you should know that the system
also supports independent search/browse agents such as mine,
<http://front.math.ucdavis.edu/>. You might also be interested in the New
York Times article about xxx, <http://xxx.lanl.gov/blurb/nyt21apr98.html>.

Following the xxx model, the IF archive could be upgraded with these
features:

o Author would contribute their games via a web upload system
like the one described at <http://front.math.ucdavis.edu/submissions.html>.
The system would do some sanity checks to make sure that the author
has contributed a game with a real title that actually runs, etc.

o Each game would be contributed with an abstract, a one-paragraph
description of the game. The abstract would have some of the value of
a review, except that it would be available with the game immediately.

o Games could be numbered by the archive, perhaps according to the year
or the month and year. For example, the 10th game contributed in 1998
could be "IF 98010" or "int-fiction/1998-10".

o The archive could encourage or require authors to provide source for
new contributions. The experience of the xxx system is that requiring
source is a Good Thing. (In the case of physics papers most of the source
is in a programmable markup language called TeX which is vaguely similar
to HTML.) For IF enthusiasts it would mean that you would always know
what is really in a game. It would also help uncover plagiarism and
adjudicate disputes. The archive could compile the source code itself
just as xxx does.

o The archive should primarily be available by http rather than ftp.
As far as I'm concerned, ftp is an ugly dinosaur. http is the future.
The mirror system should probably also be extended to other countries,
at the very least to Australia and India.

o The archive could automatically announce new arrivals each day to a
mailing list of subscribers.

o The archive could be maintained with the explicit guarantee that the
games will be preserved and freely available in perpetuity.

o The archive could have *version control*. When you revise a paper
at xxx, all old versions are still available. This means that authors
can't try to rewrite the past. It would mean for IF'ers that people
would no longer idly speculate what interesting features were in old
versions of games. All versions would be explicitly dated.

o Users could be encouraged to browse the archive with a Z-code
interpreter as the brower's helper, just as most people browse xxx with
the aid of a Postscript or PDF previewer.

If the IF archive were redesigned along the lines of xxx, it could
noticeably accelerate the production, peer review, and distribution
of freeware IF. It could expand the freeware IF community and make it
more serious.
--
/\ Greg Kuperberg (UC Davis)
/ \
\ / Visit the xxx Math Archive Front at http://front.math.ucdavis.edu/
\/ * Mathematics should be selected and not censored *

Doeadeer3

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to

I would email all those suggestions to Volker and David.

However, I also wouldn't expect much, ftp.gmd.de is maintained by volunteers,
in their spare time, on a server that has other primary uses (a business as I
understand it, maybe a government agency, I've never been totally clear on
that).

And, personally, I think it is fine the way it is (and I am da*n glad it is
there).

Doe :-) BTW - There are also several web pages already in existence that point
to it.
(And I am pretty sure they are mentioned in both the rgif and raif faqs.)

Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain

Simon 'tufty' Stapleton

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
gr...@manifold.math.ucdavis.edu (Greg Kuperberg) writes:

Greg. Having read your post, I feel the need to respond.


>
> o Author would contribute their games via a web upload system
> like the one described at <http://front.math.ucdavis.edu/submissions.html>.
> The system would do some sanity checks to make sure that the author
> has contributed a game with a real title that actually runs, etc.

Erm - How would the system check that the game has a 'real' title?
or that it works? What about all the other stuff that is on gmd?



> o Each game would be contributed with an abstract, a one-paragraph
> description of the game. The abstract would have some of the value of
> a review, except that it would be available with the game immediately.

Don't we got abstracts already? Volker has.

> o Games could be numbered by the archive, perhaps according to the year
> or the month and year. For example, the 10th game contributed in 1998
> could be "IF 98010" or "int-fiction/1998-10".

And how, exactly, is this better than the current system where games
and files are given a meaningful name. Remember what happened when
Zarf's 'Spider and Web' was actually named 'Tangle.z5'?

> o The archive could encourage or require authors to provide source for
> new contributions. The experience of the xxx system is that requiring
> source is a Good Thing. (In the case of physics papers most of the source
> is in a programmable markup language called TeX which is vaguely similar
> to HTML.) For IF enthusiasts it would mean that you would always know
> what is really in a game. It would also help uncover plagiarism and
> adjudicate disputes. The archive could compile the source code itself
> just as xxx does.

Why? If people want to give their source, they give it anyway. If they
don't, they don't have to. I, for one, would refuse to upload to a
server that *required* source (even, probably, if I was intending to
release the source anyway). Is plagiarism such a huge problem in
freeware IF? Would this really help anyway? I doubt it.

> o The archive should primarily be available by http rather than ftp.
> As far as I'm concerned, ftp is an ugly dinosaur. http is the future.
> The mirror system should probably also be extended to other countries,
> at the very least to Australia and India.

HTTP is not necessarily the future. HTTP is the present. We don't
know what the future is. What we do know is that HTTP is in a constant
state of flux. FTP, by contrast, is relatively stable. Most everyone
who can get onto the 'net can get FTP access. Even if they can't get
HTTP. I occasionally connect with my old (1987) Mac SE. It *can* run
a browser, but it's painful, and most any site that has graphics is
useless, due to the prevalence of imagemaps and bad colour choices.
FTP, however, is entirely do-able. And you can always build an HTTP
frontend for those who don't want to deal with the dinosaur. I
wouldn't use it, as FTP is blindingly fast compared to HTTP. Even on
my G3.

> o The archive could automatically announce new arrivals each day to a
> mailing list of subscribers.

Volker does that anyway. Not daily (and not that we'd want to put
that much work on him anyway), but the number of new files uploaded
is minimal.

> o The archive could be maintained with the explicit guarantee that the
> games will be preserved and freely available in perpetuity.

Hmmmm. Yes. I don't see that this is likely to be a problem.

> o The archive could have *version control*. When you revise a paper
> at xxx, all old versions are still available. This means that authors
> can't try to rewrite the past. It would mean for IF'ers that people
> would no longer idly speculate what interesting features were in old
> versions of games. All versions would be explicitly dated.

Nice idea. For completists only of course, but there seem to be a
few of *them* around here :)

> o Users could be encouraged to browse the archive with a Z-code
> interpreter as the brower's helper, just as most people browse xxx with
> the aid of a Postscript or PDF previewer.

Also a nice idea. Only relevant for some of the files on GMD, though.
What about the rest? HTML-TADS browser plugins, anyone? HUGO?
Thought not.

> If the IF archive were redesigned along the lines of xxx, it could
> noticeably accelerate the production, peer review, and distribution
> of freeware IF. It could expand the freeware IF community and make it
> more serious.

I disagree.
re: production - The amount of time I spend scouring GMD for those
last little library contributions is miniscule compared to the amount
of time I spend coding. Any time improvement, even if massive in scale,
at the GMD end would probably only reduce the amount of time in producing
the average game by minutes at best.

Anyway. Sorry about the testy tone of all this but personally I have
no problem with the situation as it is.

Also, you should note, when posting to raif you *must* include at
least one reference to tachyons.

Actually, it's beginning to sink in that this could well be an
elaborate troll.

Simon "Hook, line and sinker" Stapleton
--
_______
| ----- | Biased output from the demented brain of
||MacOS|| Simon Stapleton.
|| NOW ||
| ----- | sstaple AT liffe DoT com
| -+-.| (if you can't figure it out...)
|洵洵洵洱
-------

Magnus Olsson

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
In article <wzd87u2...@no.bloody.where>,
Simon 'tufty' Stapleton <nob...@no.bloody.where> wrote:
>gr...@manifold.math.ucdavis.edu (Greg Kuperberg) writes:

Is this the Greg Kuperberg who wrote the arcade game "J-Bird"?

>
>Greg. Having read your post, I feel the need to respond.
>>
>> o Author would contribute their games via a web upload system
>> like the one described at <http://front.math.ucdavis.edu/submissions.html>.
>> The system would do some sanity checks to make sure that the author
>> has contributed a game with a real title that actually runs, etc.
>
>Erm - How would the system check that the game has a 'real' title?
>or that it works? What about all the other stuff that is on gmd?

I must say that I fail to see how the system could check all those
things without involving a human in the loop. (Which is, essentially,
what we have today: all uploads to the IF archive are checked manually).

>> o Each game would be contributed with an abstract, a one-paragraph
>> description of the game. The abstract would have some of the value of
>> a review, except that it would be available with the game immediately.
>
>Don't we got abstracts already? Volker has.

I think the difference would be that the uploader would be required to
provide an abstract, which is not a bad idea at all.

>> o Games could be numbered by the archive, perhaps according to the year
>> or the month and year. For example, the 10th game contributed in 1998
>> could be "IF 98010" or "int-fiction/1998-10".
>
>And how, exactly, is this better than the current system where games
>and files are given a meaningful name. Remember what happened when
>Zarf's 'Spider and Web' was actually named 'Tangle.z5'?

IMHO, it would be considerably *worse*. For crying out loud, I think
of "So Far" as "So Far", not the N:th game uploaded in 19xx.

The various comp.sources archives number contributions seequentially.
I've always found that system quite confusing.

Of course, if we add an HTML interface to the archive that's searchable
by name then this would be transparent to the user. However, in that
case we could just as well archive the games under their "real" names
and let the indexprovide the serial numbers.

>> o The archive could encourage or require authors to provide source for
>> new contributions. The experience of the xxx system is that requiring
>> source is a Good Thing.

I think there's a very large difference between academic software and
games. What works in one world doesn't necessarily do so in the other.

Apart from that, I think that *encouraging* authors to provide source
is a good idea. *Requiring* them to do so is, IMNSHO, a *bad* idea.

>> For IF enthusiasts it would mean that you would always know
>> what is really in a game.

Well, yes, but I doubt that the demand for this is very big.

>> It would also help uncover plagiarism and
>> adjudicate disputes.

You don't happen to be a lawyer trolling for business, do you? :-)

Frankly, I think you're letting your imagination run away with you
here. Just how many such disputes and charges of plagiarisms have
there been? To my knowledge, none.

Besides, most (hypothetical) charges of plagiarism would probably
consider things like text, plot or puzzles, which are just as apparent
from executables as from the source. Source code would only be needed
when someone claimed theft of actual code; however, most IF authors
seem to encourage "borrowing" of code as long as the "literary" aspects
aren't copied.

>> The archive could compile the source code itself
>> just as xxx does.

Now you've left realism *way* behind. Have you *any* idea of what this
would require? Unless, of course, you forced all authors to use the
same language with the same libraries (way, Inform 6.14 with the 6/4
libraries).

>> o The archive should primarily be available by http rather than ftp.
>> As far as I'm concerned, ftp is an ugly dinosaur. http is the future.
>> The mirror system should probably also be extended to other countries,
>> at the very least to Australia and India.
>
>HTTP is not necessarily the future. HTTP is the present. We don't
>know what the future is. What we do know is that HTTP is in a constant
>state of flux. FTP, by contrast, is relatively stable. Most everyone
>who can get onto the 'net can get FTP access. Even if they can't get
>HTTP. I occasionally connect with my old (1987) Mac SE. It *can* run
>a browser, but it's painful, and most any site that has graphics is
>useless, due to the prevalence of imagemaps and bad colour choices.
>FTP, however, is entirely do-able. And you can always build an HTTP
>frontend for those who don't want to deal with the dinosaur. I
>wouldn't use it, as FTP is blindingly fast compared to HTTP. Even on
>my G3.

This is an important point.

As for extending the mirror system, well, nothing prevents you from
doing that today, as long as you can find someone willing to run the
mirrors in those countries.

>> o The archive could automatically announce new arrivals each day to a
>> mailing list of subscribers.
>
>Volker does that anyway. Not daily (and not that we'd want to put
>that much work on him anyway), but the number of new files uploaded
>is minimal.

The idea of a mailinglist is a good one, since not everybody reads
rec.*.int-fiction. Volker?

As for daily announcements: it would be premature to announce an
upload until the file in question is checked and filed in the correct
place. If you can automate that process, which I doubt very much, it
might make sense to announce files as soon as the process was
completed; with today's manual system, it makes much more sense (in
terms of Volker's workload) to batch the announcements like today.

>> o The archive could be maintained with the explicit guarantee that the
>> games will be preserved and freely available in perpetuity.
>
>Hmmmm. Yes. I don't see that this is likely to be a problem.

It would certainly be nice to have such a guarantee, but who would
guarantee it? The minimal requirement would be that some money be set
aside for handling a debacle like the shutdown of WSMR-Simtel20 (a
huge freeware archive amintained by the US Army that was shut down a
few years ago).


>> o The archive could have *version control*. When you revise a paper
>> at xxx, all old versions are still available. This means that authors
>> can't try to rewrite the past. It would mean for IF'ers that people
>> would no longer idly speculate what interesting features were in old
>> versions of games. All versions would be explicitly dated.
>
>Nice idea. For completists only of course, but there seem to be a
>few of *them* around here :)

This is a good idea, as long as the authors want those old, presumably
buggy, versions of the game to stay around. Not all authors want
that. Should those who don't be barred from distributing their games?

>> o Users could be encouraged to browse the archive with a Z-code
>> interpreter as the brower's helper, just as most people browse xxx with
>> the aid of a Postscript or PDF previewer.
>
>Also a nice idea. Only relevant for some of the files on GMD, though.
>What about the rest? HTML-TADS browser plugins, anyone? HUGO?
>Thought not.
>

This is not really meant as a flame, but the more I read of Greg's
post, the more I begin to wonder if he's inhabiting the same world
as we do.

>> If the IF archive were redesigned along the lines of xxx, it could
>> noticeably accelerate the production, peer review, and distribution
>> of freeware IF. It could expand the freeware IF community and make it
>> more serious.
>
>I disagree.

I think it would considerable worsen the situation in some ways, but
imposing a lot of bureaucratic constraints on what authors may do or
not do with their games. We're talking about an artistic activity
here, for crying out loud, not about academic research. Would you want
to handle short stories the same way as academic papers, and manage,
say, SF magazines the way you manage Physics Review Letters? I
sincerely hope not!

But the biggest problem is that this would take an enormous amount
of time, money and manpower to get going, not to speak of server resources.

Are *you* willing to donate those commodities?

>Actually, it's beginning to sink in that this could well be an
>elaborate troll.

Possibly, but I think it's too intellectual to be a troll and too
humour-free to be satire.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------

Volker Blasius

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
Greg Kuperberg wrote:
> ... [many suggestions]

Ecellent ideas. Please take over and reorganize the archive in any way
you like.

This is not a joke. I mean it.

Volker

Andrew Plotkin

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
Simon 'tufty' Stapleton (nob...@no.bloody.where) wrote:

> And how, exactly, is this better than the current system where games
> and files are given a meaningful name. Remember what happened when
> Zarf's 'Spider and Web' was actually named 'Tangle.z5'?

If I said "that was deliberate," would you all throw rotten tomatoes at
me? :)

--Z

--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Stephen van Egmond

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
I think by this point we've distilled the original article down to the
applicable ideas. LANL has money. The if-archive is volunteer.

I'm not sure that Lawrence is aware of the HTTP interface I've written to
the if-archive at http://bang.ml.org/if-archive/

In article <704m0h$c88$1...@bartlet.df.lth.se>,


Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>I think the difference would be that the uploader would be required to
>provide an abstract, which is not a bad idea at all.

I believe in practice, Volker (or whichever of the if-archive's
maintainers does this) has to be given some idea of what he's
looking at before he can process it or write a description.

>Of course, if we add an HTML interface to the archive that's searchable
>by name then this would be transparent to the user. However, in that
>case we could just as well archive the games under their "real" names
>and let the indexprovide the serial numbers.

I'm not sure that going by serial numbers is an improvement by any
stretch. This is a back-end issue entirely.

>>Volker does that anyway. Not daily (and not that we'd want to put
>>that much work on him anyway), but the number of new files uploaded
>>is minimal.
>
>The idea of a mailinglist is a good one, since not everybody reads
>rec.*.int-fiction. Volker?

I may have something to contribute here. I run a nightly job on the
bang.ml.org machine, and as part of its work it spews out a diff of
if-archive/Master-Index, comparing the last one to the current one.

It is possible to have this processed by a Perl script into a summary of
removed and new files. When someone does a reorganization, of course,
you'd have a lot of removed/added pairs, but who cares.

*

From my perspective, the only weakness in the if-archive setup as it
stands now is that the indexing is done manually: those itty-bitty Index
files are written manually, and sometimes they get out of sync with the
actual files. Other things are just hard to handle (e.g. the "competition
directory format" at
http://bang.ml.org/if-archiveXgamesXcompetition98.html ) from a Perl
script's point of view, but I've been planning on fixing that for some
time now.


--
,,,
(. .)
+--ooO-(_)-Ooo------------ --- -- - - - -
| Stephen van Egmond http://bang.ml.org/

Andrew Plotkin

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
Greg Kuperberg (gr...@manifold.math.ucdavis.edu) wrote:
> The IF community here, which
> includes some highly competent and highly motivated software developers
> and site administrators, could learn many lessons from the history
> of the xxx archive system <http://xxx.lanl.gov/>. With over 80,000
> freely available research articles, this system has had a major impact on
> scholarly communication in physics.

There have been a few disagreeing replies, and I think this is the key
point. There aren't 80000 freely available text games! We have a much
lower volume, and many of the problems that xxx takes pains to solve just
aren't problems for us.

Rather than going point by point, I'll pull out the things that I think
*would* be useful for us.
HTTP access in parallel with (but not replacing) FTP.
A one-paragraph abstract for each game, submitted by author
A searchable/browsable index of title, author, development system, and
abstract

Of these, the first already exists. (wuarchive mirror -- doesn't contain
the incoming directory)

The second and third -- David Cornelson runs an IF library on a web page,
which does more or less that sort of thing. I don't know if it's gotten
very much use. I put in abstracts and info on my games, for example, but I
don't go there to look. Part of the problem is that it's separate from the
gmd.de site. Another part is that authors (including me) are just lazy.

There's also, for example, Baf's Guide, which is a near-complete index of
the IF archive (though only updated every few months.) It's indexed a
whole bunch of ways, and easy to find things on. On the other hand, it's
one person's opinion -- which is why it doesn't suffer from the
lazy-author problem :-) -- so the game descriptions are capsule reviews,
not abstracts.

> If the IF archive were redesigned along the lines of xxx, it could
> noticeably accelerate the production, peer review, and distribution
> of freeware IF.

What problems with peer review and distribution are you seeing? (I can
assure you that the *production* of IF doesn't bottleneck on the
distribution system. :-)

Really, I find it hard to understand what you're trying to solve.

Magnus Olsson

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
In article <erkyrathF...@netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>Simon 'tufty' Stapleton (nob...@no.bloody.where) wrote:
>
>> And how, exactly, is this better than the current system where games
>> and files are given a meaningful name. Remember what happened when
>> Zarf's 'Spider and Web' was actually named 'Tangle.z5'?
>
>If I said "that was deliberate," would you all throw rotten tomatoes at
>me? :)


Yes. Here's a virtual tomato:

\|/
-o-
/|\ Splat!

:-)

Magnus Olsson

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
In article <erkyrathF...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:

[About a proposal to re-organize not only the IF archive, but the entire
way it's run]

>Really, I find it hard to understand what you're trying to solve.

Not to be hard on the proposer, but I really think this proposal
can be categorized as a solution in search of a problem.

Magnus Olsson

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
In article <3625FB1B...@gmd.de>,

Well, this is of course your prerogative, Volker, but I think it would
be a great loss to the IF community if you were to let go of the
IF archive.

Especially, of course, if the person taking over tried to enforce
rules such as all games being submitted as source (and source compilable
by the archive system, to boot).

Jacob Weinstein

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
You know, there's been an awful lot of negativity about these proposed
modifications to the IF archive, but I just wanted to point out that there
is already an IF archive that meets every single one of these standards:
the RAIF-POOL archive.


> o Author would contribute their games via a web upload system
> like the one described at <http://front.math.ucdavis.edu/submissions.html>.

Every single game ever uploaded to the RAIF-POOL archive has been uploaded
through a web front end.

> o Each game would be contributed with an abstract, a one-paragraph
> description of the game.

There is not a single game on the RAIF POOL archive that lacks a complete
and thorough abstract.



> o Games could be numbered by the archive, perhaps according to the year
> or the month and year. For example, the 10th game contributed in 1998
> could be "IF 98010" or "int-fiction/1998-10".

Every game on the archive is organized in three seperate ways: date of
uploading; date of creation; and date of birth of author.

> o The archive could encourage or require authors to provide source for
> new contributions.

You will not find a single game on the RAIF-POOL archive that does not
have source. This has proven invaluable in uncovering plagiarism, because
for every game written in RAIF-POOL, there are literally thousands that
have whole sections of code duplicated.

> o The archive should primarily be available by http rather than ftp.

Not only is the RAIF-POOL available by http, it's available at literally
EVERY PAGE of EVERY SINGLE WEB SITE in the world. Log onto any web site.
Go ahead, I dare you. Then tell me one single RAIF-POOL game that isn't
clearly indexed on that site. You can't! It's impossible! Give it up, you
poor deluded fool!

> o The archive could automatically announce new arrivals each day to a
> mailing list of subscribers.

In fact, the RAIF-POOL archive sends out updates instantaneously, and
everybody in the whole world is on the list. Again, I'm not exagerating. I
promise that there will never be a game uploaded to the RAIF-POOL archive
without every man, woman, and child in the world being informed of it.



> o The archive could be maintained with the explicit guarantee that the
> games will be preserved and freely available in perpetuity.

Well, I can ALMOST guarantee this. The only thing that could possibly ruin
my near-perfect system would be if somebody actually, somehow, some day,
wrote a game in RAIF-POOL. But I'm guessing we're all pretty safe.

Best,
Jacob Weinstein

--
To reply to me by personal e-mail, spell "edu" correctly in my e-mail address.

Rybread Celsius

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
erky...@netcom.com (Andrew Plotkin) wrote:

>Simon 'tufty' Stapleton (nob...@no.bloody.where) wrote:

>> And how, exactly, is this better than the current system where games
>> and files are given a meaningful name. Remember what happened when
>> Zarf's 'Spider and Web' was actually named 'Tangle.z5'?

>If I said "that was deliberate," would you all throw rotten tomatoes at
>me? :)

They did with Symetry [sic (can I sic myself, should I?)] was called reflect.z5.

Then again, I wrote it...


Jonadab the Unsightly One

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
Magnus Olsson <m...@bartlet.df.lth.se> wrote in article
<70523p$5kd$1...@bartlet.df.lth.se>...

> Well, this is of course your prerogative, Volker, but I think it
would
> be a great loss to the IF community if you were to let go of the
> IF archive.
>
> Especially, of course, if the person taking over tried to enforce
> rules such as all games being submitted as source (and source
compilable
> by the archive system, to boot).

I couldn't agree more. I prefer the current system.

If Mr. Blasius *does* get tired of the archive, I hope we can
find someone else to maintain it similarly. I don't mind
a little change, but the sort of things that post suggested
are, IMO, completely out of the question.

Greg Kuperberg

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
People have expressed a lot of opinions in response to my original
posting. Let me respond two in particular that are worth
discussing:

o Isn't upgrading the archive a solution in search of a problem?

Yes and no. If you want me to say specifically what could be better
about the IF archive, it is this: I just tried to download I-0 via
the best existing guide to the archive, the one by Carl Muckenhoupt.
After two or three minutes, it had finally connected to ftp. After
another two or three minutes it had transferred 3% of the file. Then I
gave up. For comparison I then went to the xxx mathematics archive
and downloaded several papers whose Postscript versions are about the
same length as I-0.z5. Each one arrived in less than *three seconds*.
Each one automatically and almost immediately appeared in my Postscript
previewer on my screen.

I admit that the archive works well enough for patient, experienced
Netizens who know exactly what game they want and where to find it.
But the long evolution of the xxx archive system has really changed
people's point of view. Instead of 80,000 sequestered mathematics
and physics papers, xxx largely functions as a kind of super-document,
a million-page book with 80,000 chapters. Wouldn't it be nice if you
could browse the IF archive (using Netscape and a Z-code helper) as
an integrated play station? If instead of saving the Z-code locally
you could just come back to the archive every day that you wanted to
continue your game? (Of course the helper can save the *state* of your
game locally.)

As for searchability and browsability, here is a URL that will
list every paper on game theory in the xxx mathematics archive:

http://front.math.ucdavis.edu/search/game+or+games

Just one more click gets you to each of the papers themselves. There is
nothing like that available for the IF archive. Even though it is .5%
of the size of xxx (assuming 400 games), it is outright *harder* to find
a game in the IF archive than a paper at xxx.

If you only know xxx in its current form, you may have the impression
that the whole thing was created a priori to house gigabytes of papers.
In fact this is not true. xxx evolved with its content. To a great
extent it has pulled in its papers. Its reliability and fast turnaround
has electrified authors as well as readers. It has cranked up the
competition among the physicists and mathematicians who contribute to it.

To the extent that my suggestions are a solution in search of a problem,
is that bad? That's exactly what people said about Netscape, about the
Internet, about the computer itself. They were all solutions in search
of problems. Few people had any idea that they were useful before they
existed. In this case, you have a pretty big hint about what could be
useful to you if it were available, if any of you care to look carefully
at the xxx system.

In fact the xxx mathematics archive has replaced a lot of other smaller
preprint archives in mathematics. Some of them were about the same size
and maintained at about the same level as the IF archive. Their users
were content with the status quo too, until they saw an alternative that
was enormously better.

o But the IF archive maintainers are just volunteers!

The word "volunteer" is in general one of the biggest red herrings on the
Net. Einstein was originally just a volunteer. Who in the IF community
isn't a volunteer? Are the games in the archive above criticism because
they were written by volunteers? Going by the comments about them in
these newsgroups, they aren't. I do appreciate the efforts of everyone
here: the archive maintainers, the reviewers, and especially Graham
Nelson as the author of Inform and the authors of the games themselves.
What strikes me is that the allocation of this wonderful volunteer labor
pool is in some respects irrational. A group of talented programmers
which has spent tens of thousands of hours writing great games isn't
willing to spend hundreds of hours developing a great game archive.
Volker Blasius is doing good work and I don't mean to demand more of
his time. That would be unfair. What I would say is that he should
have help from some of the other highly motivated people here.

Of course Volker's suggestion is that I should help. As was astutely
pointed out, I wouldn't be the right person since I do in fact live
in a different world. Some of the specifics of my suggestions were a
little off and would need to be adjusted to reality. (Regrettably for
this reason some people missed the forest for the trees when reading
my posting.) But for the record, I do maintain the Front to the
xxx Mathematics Archive as a volunteer. The xxx operation itself was
maintained for several years by a single volunteer. It is true that it
now has a full-time staff of four people. But if we assume that the IF
archive takes 20% of Volker's time, then archiving one IF game (assuming
that there are 400 of them) still takes ten times as much human effort
as archiving one physics paper.

Mary K. Kuhner

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
A couple of points to bear in mind in thinking about the IF archives:

(1) GMD.DE is a single machine of limited capacity, and IF is not its
sole or even primary purpose. Unless another machine (and associated
maintenance and sysadmin costs) could be provided, it is not a good idea
to increase the computational load of the archive.

(2) IF players frequently use older systems (since IF is one of the few
things available that will *run* on older systems) so as a user base we
are very different from the norm. Therefore, it's unwise to assume
things like web browsers, postscript display programs, graphical interfaces,
etc. The IF community is not so big that it can afford to alienate
a large subgroup of players by such choices.

(3) If you're in the US, it would be better to access one of GMD's
mirrors, rather than the site itself: it's no wonder that's slow, given
that GMD is in Germany. No amount of rearrangement will make up for
the intercontinental connection problem. I have visited GMD's web
page from the US: at least when I did so, it was much slower than
GMD's FTP access, to the point of being pretty unbearable. It's not
fair to compare a Web server in California with an FTP server in Germany
(calling in from California) and conclude FTP is slower. I can't imagine
why FTP would actually be slower (feel free to enlighten me): my
experience is that it's always faster. I can FTP files from my local
machine a heck of a lot quicker than I can bring them up in Netscape.

I would not object to an HTML interface into the archives *if* we
didn't overload volunteer capacities in the process, and *if* people
who needed plain FTP could still easily get it.

Mary Kuhner mkku...@genetics.washington.edu

Greg Kuperberg

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
In article <705p4j$je0$1...@nntp3.u.washington.edu>,

Mary K. Kuhner <mkku...@kingman.genetics.washington.edu> wrote:
>(1) GMD.DE is a single machine of limited capacity, and IF is not its
>sole or even primary purpose. Unless another machine (and associated
>maintenance and sysadmin costs) could be provided, it is not a good idea
>to increase the computational load of the archive.

First I must say that it's refreshing to see a less defensive
response than many of the ones so far.

The Front for the xxx Mathematics archive handles 1,500 page views
per day and runs on a $2000 Linux box. Without any optimiziation of
its extremely inefficient software, it could handle ten times as many.
With optimization, a hundred or a thousand times as many. On the scale
of the IF archive, computer capacity is essentially free. It would
be strange if no one could spare more than 10% of a machine with a
depreciated value of $100 for the IF archive.

>(2) IF players frequently use older systems (since IF is one of the few
>things available that will *run* on older systems) so as a user base we
>are very different from the norm. Therefore, it's unwise to assume
>things like web browsers, postscript display programs, graphical interfaces,
>etc. The IF community is not so big that it can afford to alienate
>a large subgroup of players by such choices.

This is a problem that the xxx archive system also has to solve.
In addition to its web features, it is available by ftp and it also
delivers documents uuencoded by e-mail. In fact e-mail document delivery
was the first xxx service when it was created by a single volunteer
in 1991, before the Web even existed. The same volunteer added ftp
service the next year. These services are maintained so that almost
any scholar can retrieve the papers from almost anywhere in the world,
e.g., a physicist in Bangladesh with a free 15-year-old IBM PC with an
e-mail only connection to the Net.

Needless to say, I'm not talking about taking away any kind of
service from anyone.

>(3) If you're in the US, it would be better to access one of GMD's
>mirrors, rather than the site itself: it's no wonder that's slow, given
>that GMD is in Germany.

It would be, but unfortunately both of the two best html interfaces for
the archive offer links to the GMD site and not to any US mirror sites.
The fact that the IF archive does not use serial-number-based URLs
encourages this. It may be useful for humans to refer to games by their
titles (and of course most people usually call math and physics papers
by their titles as well), but the effective computer name of a game in
the archive is its entire path:

ftp://ftp.gmd.de/if-archive/games/zcode/Adventureland.z5

or at least everything from "if-archive/..." onward. If the system
relied more on serial numbers and less on ad hoc paths, people writing
interfaces could more easily rely on mirror sites.

By comparison, the Front for the xxx Mathematics Archive is just an
interface to a globally distributed archive (developed by a single
volunteer, me). It determines the URL based on the Internet address of
the browser's computer. So if you browse the Front from France, it gives
URLs to papers beginning with http://xxx.lpthe.jussieu.fr/, while if you
read it from the US, the pointers begin with http://xxx.lanl.gov/. If it
can't guess the geographical location of the browser, it defaults to LANL.

> It's not fair to compare a Web server in California with an FTP server
> in Germany (calling in from California) and conclude FTP is slower.
> I can't imagine why FTP would actually be slower (feel free to enlighten
> me): my experience is that it's always faster. I can FTP files from
> my local machine a heck of a lot quicker than I can bring them up
> in Netscape.

[Actually I was comparing the ucdavis.edu-to-lanl.gov connection to the
ucdavis.edu-to-Germany connection.]

There is a fundamental incompatibility between ftp and http which
makes ftp completely inferior if you retrieve small-to-medium-sized
files using any web browser. ftp is a *stateful* data protocol, which
means that the browser logs in to the remote site and has a dialogue.
http is *stateless*, i.e., optimized to handle a single file request.
With decent internet connections, http is almost always fast enough for
me for a file under one megabyte; ftp within the US can be very slow
even for a 1k README file.

Besides, http is supported by better security and better usage logs than
ftp, and has many other extra features.

John Francis

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
In article <705sgh$mt5$1...@manifold.math.ucdavis.edu>,

Greg Kuperberg <gr...@manifold.math.ucdavis.edu> wrote:
>In article <705p4j$je0$1...@nntp3.u.washington.edu>,
>Mary K. Kuhner <mkku...@kingman.genetics.washington.edu> wrote:
>>(1) GMD.DE is a single machine of limited capacity, and IF is not its
>>sole or even primary purpose. Unless another machine (and associated
>>maintenance and sysadmin costs) could be provided, it is not a good idea
>>to increase the computational load of the archive.
>
>First I must say that it's refreshing to see a less defensive
>response than many of the ones so far.

If you barge into an area where you have demonstrated lack of some
basic understanding of the situation, don't be surprised if you get
told as much. We're not being defensive - you're being offensive :-)

>The Front for the xxx Mathematics archive handles 1,500 page views
>per day and runs on a $2000 Linux box. Without any optimiziation of
>its extremely inefficient software, it could handle ten times as many.
>With optimization, a hundred or a thousand times as many. On the scale
>of the IF archive, computer capacity is essentially free. It would
>be strange if no one could spare more than 10% of a machine with a
>depreciated value of $100 for the IF archive.

Ah. But who is going to pay for the net connection?
That's far more expensive than the actual hardware.
Don't forget the "associated maintenance and sysadmin costs"

>>(3) If you're in the US, it would be better to access one of GMD's
>>mirrors, rather than the site itself: it's no wonder that's slow, given
>>that GMD is in Germany.
>
>It would be, but unfortunately both of the two best html interfaces for
>the archive offer links to the GMD site and not to any US mirror sites.

A valid point.

>The fact that the IF archive does not use serial-number-based URLs
>encourages this.

A questionable assumption, even under the most charitable interpretation.

> It may be useful for humans to refer to games by their
>titles (and of course most people usually call math and physics papers
>by their titles as well), but the effective computer name of a game in
>the archive is its entire path:
>
> ftp://ftp.gmd.de/if-archive/games/zcode/Adventureland.z5
>
>or at least everything from "if-archive/..." onward. If the system
>relied more on serial numbers and less on ad hoc paths, people writing
>interfaces could more easily rely on mirror sites.

Why is a serial number any more or less easy to handle than a string?
Making people do something difficult just to make the machines job a
little easier is normally a sign of poorly-designed software.
For an archive the size of gmd, the (questionable) increase in efficiency
you could achive by using direct numeric indices rather than a text-based
naming & keyword scheme doesn't seem worth the cost.
(The paths (after if-archive) are, after all, the same on both the
original and the mirror site - that's what being a mirror site means.
And they're not entirely 'ad hoc' - they follow a well-defined scheme)

>By comparison, the Front for the xxx Mathematics Archive is just an
>interface to a globally distributed archive (developed by a single
>volunteer, me).

Fine. It's a good start, but you could adapt it somewhat.
It's natural for you to try and fit our problem to your solution,
but we really don't need a hammer. Offer us a wrench, though ...

> It determines the URL based on the Internet address of
>the browser's computer. So if you browse the Front from France, it gives
>URLs to papers beginning with http://xxx.lpthe.jussieu.fr/, while if you
>read it from the US, the pointers begin with http://xxx.lanl.gov/. If it
>can't guess the geographical location of the browser, it defaults to LANL.

A very nice idea. This could be done, today, to point to the GMD mirrors.

>> It's not fair to compare a Web server in California with an FTP server
>> in Germany (calling in from California) and conclude FTP is slower.
>> I can't imagine why FTP would actually be slower (feel free to enlighten
>> me): my experience is that it's always faster. I can FTP files from
>> my local machine a heck of a lot quicker than I can bring them up
>> in Netscape.
>
>[Actually I was comparing the ucdavis.edu-to-lanl.gov connection to the
>ucdavis.edu-to-Germany connection.]
>
>There is a fundamental incompatibility between ftp and http which
>makes ftp completely inferior if you retrieve small-to-medium-sized
>files using any web browser. ftp is a *stateful* data protocol, which
>means that the browser logs in to the remote site and has a dialogue.
>http is *stateless*, i.e., optimized to handle a single file request.
>With decent internet connections, http is almost always fast enough for
>me for a file under one megabyte; ftp within the US can be very slow
>even for a 1k README file.

But you seem to be assuming that ftp access is done *through a browser*.
As Mary said, that's not the norm for the if-archive.

>Besides, http is supported by better security and better usage logs than
>ftp, and has many other extra features.

Which are all irrelevant if you don't happen to be using a browser.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.

Damien Neil

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
On 15 Oct 1998 15:21:05 -0700, Greg Kuperberg <gr...@manifold.math.ucdavis.edu>
wrote:

>With decent internet connections, http is almost always fast enough for
>me for a file under one megabyte; ftp within the US can be very slow
>even for a 1k README file.

As you correctly point out, FTP connections involve an initial setup
cost higher than that of HTTP. I would be very much surprised, however,
if there were much difference in the transfer rate once this initial
setup is completed. In other words, FTP is indeed likely to be slower
if you wish only to retrieve a 1k file. The difference in speed is likely
to be not very noticable when retrieving larger files, however.

There is, however, another consideration. It is rare for a person to
only transfer a single file. A session generally follows a sequence of
"connect, view index, view subindex, retrieve file, lather, rinse, repeat."
In this case, the initial setup costs of FTP become negligable across the
session. HTTP, however, imposes a continual per-transaction overhead,
as a new TCP connection must be formed for each request.

In my experience, any protocol speed differences are overwhelmed by
the quality of the network connection.

>Besides, http is supported by better security and better usage logs than
>ftp, and has many other extra features.

Better security features? Well, encrypted transfers using SSL are
certainly far more secure than FTP. I don't see much need for this,
however.

Better usage logs? I invite you to tell me in what way the usage logs
of the HTTP server of your choice are superior to those of wuftpd, to
pick an example out of my hat.

Extra features? HTTP is nearly featureless; this is one of its great
appeals.

- Damien

David Glasser

unread,
Oct 15, 1998, 3:00:00 AM10/15/98
to
Greg Kuperberg <gr...@manifold.math.ucdavis.edu> wrote:

> As a very occassional reader of r.g.i-f, I would like to offer an outside
> perspective on the task of archiving the world's free Interactive Fiction.
> (I played Christminster and Reverberations and dabbled a little with
> a few others, that's about it.) The IF archive is certainly much more
> convenient than no IF archive, and it is good that it is complete. But

> there is a great deal that it does not do. The IF community here, which


> includes some highly competent and highly motivated software developers
> and site administrators, could learn many lessons from the history
> of the xxx archive system <http://xxx.lanl.gov/>. With over 80,000
> freely available research articles, this system has had a major impact on
> scholarly communication in physics.

First off, I think it's nice that you want to help, and appreciate your
ideas. Of course, because you have challenged our way of life, I must
bash everything you said :-)

> If you want to evaluate xxx, you should know that the system
> also supports independent search/browse agents such as mine,
> <http://front.math.ucdavis.edu/>. You might also be interested in the New
> York Times article about xxx, <http://xxx.lanl.gov/blurb/nyt21apr98.html>.

I use an offline newsreader and have not looked at xxx, but I will
tomorrow or so. Keep in mind that I'm just talking about your comments,
not xxx. I know I shouldn't be doing this.

> Following the xxx model, the IF archive could be upgraded with these
> features:
>

> o Author would contribute their games via a web upload system
> like the one described at <http://front.math.ucdavis.edu/submissions.html>.

> The system would do some sanity checks to make sure that the author
> has contributed a game with a real title that actually runs, etc.

Not a bad idea. The main problem is that that would be quite
complicated. For example, not everything contributed to the if-archive
is a game, let alone an Inform game with a title.

> o Each game would be contributed with an abstract, a one-paragraph

> description of the game. The abstract would have some of the value of
> a review, except that it would be available with the game immediately.

This is required, though not automatic. Email the maintainers,
basically.

> o Games could be numbered by the archive, perhaps according to the year
> or the month and year. For example, the 10th game contributed in 1998
> could be "IF 98010" or "int-fiction/1998-10".

Would these be symlink-type-things or the only place they are?

Of course, don't forget that any good ftp client lets you sort by date.

> o The archive could encourage or require authors to provide source for

> new contributions. The experience of the xxx system is that requiring

> source is a Good Thing. (In the case of physics papers most of the source
> is in a programmable markup language called TeX which is vaguely similar

> to HTML.) For IF enthusiasts it would mean that you would always know
> what is really in a game. It would also help uncover plagiarism and
> adjudicate disputes. The archive could compile the source code itself
> just as xxx does.

The thing is, AFAIK, TeX doesn't have secrets. IF does. Many people
have problems with uploading source. Plagiarism tends not to happen
much.

However, a bigger recommendation for uploading source would be good.

> o The archive should primarily be available by http rather than ftp.

> As far as I'm concerned, ftp is an ugly dinosaur. http is the future.
> The mirror system should probably also be extended to other countries,
> at the very least to Australia and India.

I disagree about your first point. I'd *much* rather be using my
wonderful ftp client Fetch than Netscape's evil downloads or IE's
well-done-but-slow-on-my-old-Mac downloads.

For your second point...we just got another mirror. Also, if you know a
site that does mirrors in au or in, tell Volker Blasius (the archive's
maintainer). He'd be glad to know. (Complete lack of sarcasm here.)

> o The archive could automatically announce new arrivals each day to a
> mailing list of subscribers.

Also, cool idea. On the other hand, Volker could do this by hand; there
is a periodical post to raif about it (and a new-since-last-post file);
and many people just check the incoming directory every day or so.

> o The archive could be maintained with the explicit guarantee that the
> games will be preserved and freely available in perpetuity.

Yep.

> o The archive could have *version control*. When you revise a paper
> at xxx, all old versions are still available. This means that authors
> can't try to rewrite the past. It would mean for IF'ers that people
> would no longer idly speculate what interesting features were in old
> versions of games. All versions would be explicitly dated.

Of course, many people don't want their embarrassing bugs sitting
around.

> o Users could be encouraged to browse the archive with a Z-code
> interpreter as the brower's helper, just as most people browse xxx with
> the aid of a Postscript or PDF previewer.

Which requires more work to write one. Though it isn't a bad idea.

> If the IF archive were redesigned along the lines of xxx, it could
> noticeably accelerate the production, peer review, and distribution

> of freeware IF. It could expand the freeware IF community and make it
> more serious.

(By the way: why is it called xxx? Sounds like a pr0n archive.)

The main problem is that Volker and David Kinder do this in their spare
time. So do all of us, really. It requires effort to get this set up.

A web page for the archive, possibly with cgi's to automate the
uploading process and to optionally check zip/z*/gam integrity would be
cool.

I'll take a look at xxx. I'll report back.

(OK, I looked today. Hate to bash it, but I didn't love it. I found it
hard to do things as simple as getting a directory listing. I wasn't
able to look at xxx or front as much as I could have, though.)

--David Glasser
gla...@NOSPAMuscom.com | http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Sadie Hawkins, official band of David Glasser: http://sadie.retina.net
"We take our icons very seriously in this class."

Matthew T. Russotto

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
In article <705p4j$je0$1...@nntp3.u.washington.edu>,
Mary K. Kuhner <mkku...@kingman.genetics.washington.edu> wrote:

}(3) If you're in the US, it would be better to access one of GMD's
}mirrors, rather than the site itself: it's no wonder that's slow, given

}that GMD is in Germany. No amount of rearrangement will make up for
}the intercontinental connection problem. I have visited GMD's web
}page from the US: at least when I did so, it was much slower than
}GMD's FTP access, to the point of being pretty unbearable.

I'm afraid your problem is domestic. I have no problem connecting to
the GMD web site or the FTP server from the US (east coast).
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

Neil K.

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
gr...@manifold.math.ucdavis.edu (Greg Kuperberg) wrote:

> [....] It could expand the freeware IF community and make it
> more serious.

Everyone else has commented ably on the issues that may arise from this
proposal, but let me say one thing.

Serious? Eeeagh! I'm quite happy that we're notably *not* serious around
here, thank you. :)

- Neil K.

--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca

Doeadeer3

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to

In article <3625FB1B...@gmd.de>, Volker Blasius <Volker....@gmd.de>
writes:

>Ecellent ideas. Please take over and reorganize the archive in any way
>you like.
>
>This is not a joke. I mean it.
>

>Volker

Awwwwwwwwwwwww. (This is what we all secretly fear.) No, no, no. You do a
great, sometimes underappreciated, job. And how could we depend on anyone else
to keep the if archive going as you have? Volunteer dependability is a hard
quality to find.

>gr...@manifold.math.ucdavis.edu (Greg Kuperberg):

>The IF archive is certainly much more
>convenient than no IF archive, and it is good that it is complete. But
>there is a great deal that it does not do.

Personally, I have always had a hard time with people who volunteer OTHER
people's time, energy and resources.

But if those people want to write improved web pages (or other systems) that
point to gmd.de (and its directories) nothing is stopping them from
VOLUNTEERING to do that on THEIR own time.

I can download much faster from an ftp than from a web page and am not sure why
others have problems (of course I don't use a browser when accessing
ftp.gmd.de).

Doe :-) Round of applause for you, Volker! Hear, hear!

Magnus Olsson

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
In article <fake-mail-161...@dialup01.nettwerk.com>,

Neil K. <fake...@anti-spam.address> wrote:
> gr...@manifold.math.ucdavis.edu (Greg Kuperberg) wrote:
>
>> [....] It could expand the freeware IF community and make it
>> more serious.
>
> Everyone else has commented ably on the issues that may arise from this
>proposal, but let me say one thing.
>
> Serious? Eeeagh! I'm quite happy that we're notably *not* serious around
>here, thank you. :)

I think this is the main incompatitibility between Greg's and our
views of what the IF community should be like. Greg seems to want to
apply the standards of the academic community to the IF community.

To this, I can only say that I think these two communities are very
different in some fundamental ways. IF works are not research papers
(or even research software). IF writers are artists (in varying senses
of the word), not researchers.

The typical IF author has different objectives when releasing a game
than a researcher has when releasing a paper or a piece of research
software. For example, the IF author may want to keep things secret
from his/her audience. Priority issues and issues of plagiarism are
quite different. The concept of "peer review" is *very* different
(Peer review in the IF world is, basically, literary criticism, it's
done after publication, and it has no formal effects. In the academic
world, it happens before publication, addresses the validity and
quality of the research, and is basically the difference between life
and death).

The feeling of most people posting here seems to be that Greg is
trying to impose the standards of a quite different field on the
IF community. Moreover, he seems to be trying to do this unilaterally;
more or less dictating that this is how things should be.

No wonder people react in a defensive manner.

David Burke

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
doea...@aol.com (Doeadeer3) wrote:

>
>Doe :-) Round of applause for you, Volker! Hear, hear!
>

Seconded.
The archive is a great resource. It is complete, that is more than we
have any right to expect from a volunteer

I find an irony to people complaining about the lack of a graphical
interface to an archive of interactive fiction :-)


--David Burke

Wanderer in the Fourth Dimension
www.btinternet.com/~david.burke/drwho2.html

Greg Kuperberg

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
In article <7072ff$20d$1...@bartlet.df.lth.se>,

Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>The typical IF author has different objectives when releasing a game
>than a researcher has when releasing a paper or a piece of research
>software. For example, the IF author may want to keep things secret
>from his/her audience. Priority issues and issues of plagiarism are
>quite different. The concept of "peer review" is *very* different.

I agree that plagiarism is a red herring, mainly because there are so
few IF games in existence. If there were ten thousand of them, I bet
it would be a real problem. I admit that I didn't think this through
in my original posting.

What I meant by "peer review" was the friendly kind: the readers/users
find bugs in a document in an archive and let the author know by e-mail.
This works more-or-less the same way in the xxx archive and in the IF
archive. Except that it's often much more embarrassing to an IF author,
since there is no requirement that the IF document include a valid e-mail
address and consequently the bugs get much more public discussion.

>(Peer review in the IF world is, basically, literary criticism, it's done
>after publication, and it has no formal effects. In the academic world,
>it happens before publication, addresses the validity and quality of
>the research, and is basically the difference between life and death).

I'm not sure how interested you are in the culture of the xxx archive
system, but since you mention it, peer review comes after the article
goes to xxx. xxx is universal and doesn't judge papers on the basis
of quality. (The staff does sometimes move papers that are off topic,
but that's a little different.)

As for academic peer review being the difference between life and death,
you've got me there. It's a good thing that I brought my Smith and
Wesson to the last department meeting. Otherwise it would have been
*** YOU HAVE DIED *** for me.

>The feeling of most people posting here seems to be that Greg is
>trying to impose the standards of a quite different field on the
>IF community. Moreover, he seems to be trying to do this unilaterally;
>more or less dictating that this is how things should be.

Right again. I have already organized a vice squad to force everyone
here to follow my suggestions. You will be interviewed by men in helmets
next week.

Magnus Olsson

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
In article <707hvi$ol6$1...@manifold.math.ucdavis.edu>,

Greg Kuperberg <gr...@manifold.math.ucdavis.edu> wrote:
>In article <7072ff$20d$1...@bartlet.df.lth.se>,
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>>The typical IF author has different objectives when releasing a game
>>than a researcher has when releasing a paper or a piece of research
>>software. For example, the IF author may want to keep things secret
>>from his/her audience. Priority issues and issues of plagiarism are
>>quite different. The concept of "peer review" is *very* different.
>
>I agree that plagiarism is a red herring, mainly because there are so
>few IF games in existence. If there were ten thousand of them, I bet
>it would be a real problem. I admit that I didn't think this through
>in my original posting.

But I think one of the problems with your proposal is that it seems to
be suitable for a world with tens of thousands of IF games (as there
are thousands of research papers today on the xxx system, if I understand
things correctly).

But these things don't scale well. In particular, the kind of procedures
you suggest might work very well for xxx, and in fact be necessary to
keep things neatly organized, but I fear that if applied to the IF
archive they would seem overly bureaucratic; the kind of rules hackers
like to call "fascist" (no resemblance to real-life fascists intended).

For example, the naming of files: if you have 8000 games, it's very
hard to come up wiht descriptive, unique filenames, so it would probably
be better just to number them. The current IF archive, however, isn't
bigger than that it allows users to distinguish files by name and
to search for them by name as well. In most of the cases, I can find
a specific game without looking at the index, whereas if they were
just numbered I would of course *have* to use the index.

Of course, if the sole access to the archive is via, say, a Web-based
interactive index or a search engine, then the issue is moot since
the actual filenames aren't seen by users.

>What I meant by "peer review" was the friendly kind: the readers/users
>find bugs in a document in an archive and let the author know by e-mail.
>This works more-or-less the same way in the xxx archive and in the IF
>archive.

Oh, I see. Since you were clearly speaking from an academic viewpoint,
I thought you meant what is usually meant by "peer review" - the process
of determining who gets published and who gets money.

>Except that it's often much more embarrassing to an IF author,
>since there is no requirement that the IF document include a valid e-mail
>address and consequently the bugs get much more public discussion.

There are two problems here:

1) Requiring a valid email address won't help if the author moves
or changes ISP's. You have the same problem for academic papers as
well, though to a lesser degree, because you can usually trace an
author through his or her employer or department. But IF authors
aren't usually affiliated with an IF writing institute... :-)

2) The public discussion of bugs is only partly caused by lack of
valid email addresses. It's more commonly caused by either a
perceived need to warn others of the bugs, or simply by a lack
of consideration.

>>(Peer review in the IF world is, basically, literary criticism, it's done
>>after publication, and it has no formal effects. In the academic world,
>>it happens before publication, addresses the validity and quality of
>>the research, and is basically the difference between life and death).
>
>I'm not sure how interested you are in the culture of the xxx archive
>system, but since you mention it, peer review comes after the article
>goes to xxx.

OK. I thought you meant the formal kind of peer review.

> xxx is universal and doesn't judge papers on the basis
>of quality. (The staff does sometimes move papers that are off topic,
>but that's a little different.)

So it's a preprint library? On a tangent (since I just discussed this
issue with some colleagues), what happens if somebody submits a paper to
xxx and then has it accepted by a printed journal? Has any journal ever
complained and asked that an article be removed from xxx because now
they owned the copyright?

>As for academic peer review being the difference between life and death,
>you've got me there. It's a good thing that I brought my Smith and
>Wesson to the last department meeting. Otherwise it would have been
>*** YOU HAVE DIED *** for me.

Actually, I wasn't exaggerating by very much. Wasn't there a case
some years ago about a Russian guest researcher in the US who shot
the head of his department because he'd been deined funding?

Personally, I don't know anybody who's shot or been shot in this kind
of quarrel, but there have been several cases of physical fighting and
assaultat Swedish department meetings. I've talked to one poor guy who
had most of his hair torn out by a disgruntled PhD student...

>>The feeling of most people posting here seems to be that Greg is
>>trying to impose the standards of a quite different field on the
>>IF community. Moreover, he seems to be trying to do this unilaterally;
>>more or less dictating that this is how things should be.
>
>Right again. I have already organized a vice squad to force everyone
>here to follow my suggestions. You will be interviewed by men in helmets
>next week.

Well, it seems that paragraph turned out a bit harsher than I
intended; my apologies for that. I of course didn't mean that you had
any ambitions to force us to do anything; just that people probably
take your original post as an attempt by an outsider (I think you
wrote yourself that you're an infrequent poster here) to prescribe
("dictate" is of course too strong a word) how we should run our
business. I realize that you're only trying to be helpful, but any
time an outsider suggest to a rather cohesive community they're doing
things in the wrong way and that he know better (which is how you post
is likely to be itnerpreted,even if you didn't mean it like that),
people will enter defensive positions almost automatically.

In retrospect (and with 20-20 hindsight), I think that if you hadn't
said "You're doing things wrong: the IF archive should be run like the
xxx archive", but "I think the way we archive and distribute IF could
be improved; perhaps we could learn a few lessons from the xxx
system?", you would have met much more positive reactions.

Greg Kuperberg

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
I looked yesterday at several important (or potentially important)
ingredients of the IF archive system: The main archive site (ftp.gmd.de)
maintained by Volker Blasius, the wuarchive.wustl.edu mirror site, Stephen
van Egmond's overlay (http://bang.ml.org/if-archive/), Carl Muckenhoupt's
overlay (http://www.wurb.com/if/index.html), and Andrew Plotkin's XZip
program (potentially useful as a Netscape helper; see below).

Overall, these sites and programs have almost all of the elements of a
slick, integrated system that would allow users to find a game with one
search request and then play it with one extra click. All it would take
is slightly closer cooperation among the main people involved.

Volker's site fulfills the crucial role of keeping the games.
Unfortunately, access to ftp.gmd.de is sometimes bad. It is not simply
a "trans-Atlantic cable problem" or a "domestic routing problem".
The Internet backbone is owned by many different telecom companies
who don't completely cooperate with each other. For trans-Atlantic
communications there are various pairwise agreements to carry traffic.
The result of this is that the trans-Atlantic bandwidth is badly
allocated; your connection to Germany may be tied up in a traffic jam on
one set of routers, while mine goes smoothly over another set of routers.

Access to wuarchive is also sometimes bad. wuarchive does many things
for many groups of people on a shoestring budget (relatively speaking).
I suspect that the wuarchive was set up as a mirror site for gmd.de
because it was close to zero work to do so. (Also wuarchive is of limited
usefulness to web users because both "Baf" and "bang" link to gmd.de.)
A really useful mirror site would have some non-zero amount of dedicated
maintainence or software.

In effect, the "URN" (universal resource name) of each game
is its specific path in the if-archive. This is cumbersome.
For comparison, both URNs and URLs in the xxx archive system
are close to the bare minimum. For example, the most recent
paper in the math archive is math.DG/9810101 (math, differential
geometry, October 1998, paper #101). Consequently its URL at xxx is
http://xxx.lanl.gov/abs/math.DG/9810101, while its URL at the Front is
http://front.math.ucdavis.edu/math.DG/9810101. The Front and xxx can
have nearly identical URLs for the same paper even though the Front is
a high-level agent and not at all a mirror site.

Let me also point out that when you give a document an id number or a
serial number, you generally give people the impression that you are
archiving or otherwise tending to the document. In the case of the IF
archive, this would be a good thing.

Of all the web interfaces I have found for the IF archive, "Baf's
Guide" is by far the most useful. Carl has has thought of most of
the basic necessary components of a good archive browser. The main
area for improvement is the primitive use of HTML. Stephen van Egmond
has more attractive HTML. Here I must mention a major pet peeve that
I have with many web sites: HTML doesn't have to be complicated or
highly magnified in order to be good. The main web pages of the New
York Times, for example, are reasonably simple (no frames, no Java)
as well as attractive and packed with information. Stephen seems to
understand this actually, but still I want to make clear that I'm not
asking for horrible kitsch on web pages.

Finally, I tried to use XZip as a Netscape helper to play the games.
It almost worked. I forgave the slow connection to ftp.gmd.de, since that
has nothing to do with XZip or Netscape. But there were the following
additional problems: It was only from past experience that I knew that I
had to invent a MIME type for Z-code games (I chose application/x-zcode),
and even so I had to tell Netscape to infer the MIME type from the file
suffix. As it happens, ftp doesn't know anything about MIME types;
that's the domain of http. It would be good to establish a standard
MIME type for Z-code.

After that, Netscape launched each game smoothly, which was good.
Unfortunately, XZip made some incorrect assumptions about what I wanted
to save. It let me save the state of a given game, but the default was
pretty bad: /tmp/M03626A5D803E5D62.sav. It had no idea that I might
want to save the Z-code of the game in my own directory (given that
Netscape put it in a temporary directory to launch the helper).

Also XZip didn't know any title or game for the name. Is it somewhere
in the Z-code? If not, maybe it could be passed from the archive to
the helper via a MIME parameter. It would be useful for the title bar
of the XZip window to be the name of the game instead of just "XZip".
I lost track of my XZip windows since I was browsing new games instead
of playing familiar ones.

Greg Kuperberg

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
In article <707qcf$lgr$1...@bartlet.df.lth.se>,

Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>Oh, I see. Since you were clearly speaking from an academic viewpoint,
>I thought you meant what is usually meant by "peer review" - the process
>of determining who gets published and who gets money.

There is a huge difference between peer review of *papers* and peer review
of *people*. I agree that peer review of people can lead to broken teeth,
attempted suicides, sex scandals, "going postal", and other regrettable
circumstances. Fortunately for free IF you can confine peer review to
vicious attacks on the games rather than the authors.

>So it's a preprint library? On a tangent (since I just discussed this
>issue with some colleagues), what happens if somebody submits a paper to
>xxx and then has it accepted by a printed journal? Has any journal ever
>complained and asked that an article be removed from xxx because now
>they owned the copyright?

The intent of xxx is to permanently archive research articles and
guarantee that they will always be freely available. All kinds of
peer review, including journals, need to be rebuilt on top of this new
foundation. It is a big change in the system of scholarly communication,
and no, some journals don't like the winds of change. In physics
and probably in math it is too late to prevent the transformation.
In some academic disciplines the more conservative publishers are taking
defensive measures to delay the spread of xxx. On the other hand,
the people involved with xxx are eager to cooperate with progressive
publishers who see opportunities in change.

There is a lesson here: If you skillfully develop a small-scale, free,
informal service on the Net, it could turn into something much bigger
and more important with big consequences for "capitalist reality".
Two other examples of this are Linux and the Internet Movie Database.

>Personally, I don't know anybody who's shot or been shot in this kind
>of quarrel, but there have been several cases of physical fighting and
>assaultat Swedish department meetings. I've talked to one poor guy who
>had most of his hair torn out by a disgruntled PhD student...

I guess you guys are still Vikings at heart.

Frank Filz

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
Damien Neil wrote:
> There is, however, another consideration. It is rare for a person to
> only transfer a single file. A session generally follows a sequence of
> "connect, view index, view subindex, retrieve file, lather, rinse, repeat."
> In this case, the initial setup costs of FTP become negligable across the
> session. HTTP, however, imposes a continual per-transaction overhead,
> as a new TCP connection must be formed for each request.
>
> In my experience, any protocol speed differences are overwhelmed by
> the quality of the network connection.

Another couple things FTP has going for it:

With ANY FTP client (at least any that I've ever seen), you can download
an entire directory of files, and go off to the coffee machine.

If you are getting many files, and are hiding behind an overloaded
firewall (and have an FTP client which uses PASV mode), download times
will be MUCH faster. HTTPs statelessness means that every transaction
needs to be munched on by the firewall. Web access is usually faster
for me at home over a 28kbps link than at work through firewalls and at
least a T1 link.

--
Frank Filz

-----------------------------
Work: mailto:ff...@us.ibm.com
Home: mailto:ff...@mindspring.com

Frank Filz

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
David Burke wrote:
>
> doea...@aol.com (Doeadeer3) wrote:
>
> >
> >Doe :-) Round of applause for you, Volker! Hear, hear!
> >
> Seconded.

Thirded...

> I find an irony to people complaining about the lack of a graphical
> interface to an archive of interactive fiction :-)

You know, thats probably the other half of why peoples dander has been
raised... The IF community has resisted (to good effect in my opinion)
wildly charging off in new directions without definite gain to be had
(just look at how conservative the improvements in the Z-Machine have
been - and despite much discussion, I don't think anyone has really
started on a 32 bit followon, though of course some elements have been
designed with such followons in mind (Glk for example)).

Jonadab the Unsightly One

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
David Glasser <gla...@NOSPAMuscom.com> wrote in article

> Not a bad idea. The main problem is that that would be quite
> complicated. For example, not everything contributed to the
if-archive
> is a game, let alone an Inform game with a title.

In fact, there are enough different systems and enough different
kinds of binaries in the if-archive that it is for all purposes
completely
impossible to achieve this. Quite possibly AI-complete, although
I can't verify that.

> > o Games could be numbered by the archive, perhaps according to
the year
> > or the month and year. For example, the 10th game contributed
in 1998
> > could be "IF 98010" or "int-fiction/1998-10".
>
> Would these be symlink-type-things or the only place they are?

I should certainly hope they'd only be symlinks. I would *not* want
to browse an archive by date.

> Of course, don't forget that any good ftp client lets you sort by
date.

Unfortunately, a lot of people only have Navigator (or worse, IE) as
an ftp client. Maybe not a high percentage, especially among
IF people (since this affliction is especially common among Windoze
users), but there are such people. (I'm not bashing Web browsers,
and I think it's great that they at least do allow access to ftp,
but
they're not the same as having an actual ftp client. Maybe some day
they will be.)

> > o The archive could encourage or require authors to provide
source for
> > new contributions.

[Snip.]

> The thing is, AFAIK, TeX doesn't have secrets. IF does. Many
people
> have problems with uploading source.

Many? Try "most" I think.

I, for one, would not ever want to upload the source code *at
the same time as the game* (unless the game is a demonstration
of some programming technique rather than a "real" game).

A year later, maybe. But it's the author's choice. The
archive has *no business* demanding source code.

> Plagiarism tends not to happen
> much.

And if code *isn't* uploaded, it's actually a lot harder
to pull off, unless all you want to plagiarise is the text,
which, as someone else pointed out, is completely
determinable without source code.

> However, a bigger recommendation for uploading source would be
good.

Oh, sure. I'll agree with that any time.

> > o The archive should primarily be available by http rather than
ftp.

*Also* I might buy. "primarily" is completely out of place here.

> > As far as I'm concerned, ftp is an ugly dinosaur. http is the
future.

I rather doubt it. I suppose Unix is also an ugly dinosaur
and Windows is the future? Let's start a flame war...

No.

Frankly, ftp and http serve *completely* different purposes.
They aren't designed for the same thing, any more than
race cars and tow trucks are designed for the same thing.

> > The mirror system should probably also be extended to other
countries,
> > at the very least to Australia and India.

I can't disagree with that. Know of any free server space
over there?

> > o The archive could have *version control*. When you revise a
paper
> > at xxx, all old versions are still available. This means that
authors
> > can't try to rewrite the past. It would mean for IF'ers that
people
> > would no longer idly speculate what interesting features were in
old
> > versions of games. All versions would be explicitly dated.
>
> Of course, many people don't want their embarrassing bugs sitting
> around.

Nor, I think, do the majority of us want to wade through multiple
versions of each game. It's not necessary. The collectors can
keep each version, but I don't think most players want several
different copies of each game.

> > o Users could be encouraged to browse the archive with a Z-code
> > interpreter as the brower's helper, just as most people browse
xxx with
> > the aid of a Postscript or PDF previewer.

Um, a lot of us pay by the hour for online time. If this is an
option it should *only* be an option. Also, we should take a poll
to see how many would use it before doing it, to see whether
there's sufficient interest. (I'm not saying there's not; I'm
saying it's worth finding out before putting a lot of work into it.)

> Which requires more work to write one. Though it isn't a bad
idea.

Not a bad idea, no. I think somebody already made a
Java version of the z-machine, no? Of course, it might
be less than trivial to make Java versions of TADS,
Hugo, Alan, Adventure Builder, AGT, AdvSys, ArcheType, ...

[Forgive me for forgetting your fave and remembering
a worse one. I picked the list mostly arbitrarily.]

> A web page for the archive, possibly with cgi's to automate the
> uploading process and to optionally check zip/z*/gam integrity
would be
> cool.

Who would do it, though? I certainly don't know enough
about cgi scripting to set up anything like that.

--

"The main drawback of Inform is that it lacks
the facility for computed COME FROM statements."

-- jonadab

Lucian Paul Smith

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
Greg Kuperberg (gr...@manifold.math.ucdavis.edu) wrote:

<some stuff, but then said:>

: In effect, the "URN" (universal resource name) of each game


: is its specific path in the if-archive. This is cumbersome.
: For comparison, both URNs and URLs in the xxx archive system
: are close to the bare minimum. For example, the most recent
: paper in the math archive is math.DG/9810101 (math, differential
: geometry, October 1998, paper #101). Consequently its URL at xxx is
: http://xxx.lanl.gov/abs/math.DG/9810101, while its URL at the Front is
: http://front.math.ucdavis.edu/math.DG/9810101. The Front and xxx can
: have nearly identical URLs for the same paper even though the Front is
: a high-level agent and not at all a mirror site.

Here is where I most disagree with you. If you limit yourself to z-code
games, as you seem to be doing, the "URN" of each game is: its name.
That's it. *All* z-code games are in the same directory, just as
(apparantly) all math papers are in the /abs/ directory at lanl.

Date and number may be important for papers--you need to know what had
been said before to make sense of the one you're currently looking at.
The same is not true of IF, in any significant sense. I can sit down and
play Zork or I can sit down and play current competition games without
worrying about which came first.

And limiting yourself to z-code games is a mistake anyway--they only
comprise a fraction of the games found on the archive. But even there, if
you limit yourself to games, the URN is then just 'gametype/filename.ext',
and not the entire path.

: Let me also point out that when you give a document an id number or a


: serial number, you generally give people the impression that you are
: archiving or otherwise tending to the document. In the case of the IF
: archive, this would be a good thing.

And if you give it a name instead of a number, you generally give people
the impression that you are archiving a piece of art instead of a piece of
reference material. In the case of Interactive Fiction, this is a good
thing.

<snip bits about other web interfaces>

A lot of this would indeed be cool to see. A 'front end' for the archive
would be a great boon for newbies, in particular, and even for veterans,
if done correctly. As I see it, the potential front end should include:

-The game title
-The game author(s)
-Some information about the game, be it genre(s) or capsule reviews
-The ability to sort by any of the three above methods.
-Links to longer reviews, if they exist.
-The ability to download the game to your computer and play it.

As I understand it, this is *exactly* what AdventureBlaster plans to be.
And I'm all for it. It's for Win95 only, but, let's face it--that's what
newbies will probably be running, anyway. And if it proved useful enough,
I'm sure some fun-loving people would port it to the Mac, or X, or
whatever.

The URL for AdventureBlaster is:

http://members.tripod.com/~abadger/ifmain.html

Uh, I can't seem to find the guy's e-mail address, but I'm sure he'd
welcome suggestions (and encouragement) for the version 2 he's working on.

-Lucian

Greg Kuperberg

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
Here brief comments on two conceptual sticking points
that seem to be coming up repeatedly:

In article <01bdf938$f07f47c0$LocalHost@jonadab>,
Jonadab the Unsightly One <jon...@zerospam.com> wrote:
>I should certainly hope [that id numbers would] only be symlinks.


>I would *not* want to browse an archive by date.

The id numbers have nothing to do with how you browse the archive.
They make it easier to keep records. In particular, they would make it
easier for software agents to add value to the archive.

No one browses books by their ISBN numbers either. But it's a good
thing that ISBN numbers exist!

>Not a bad idea, no. I think somebody already made a
>Java version of the z-machine, no? Of course, it might
>be less than trivial to make Java versions of TADS,
>Hugo, Alan, Adventure Builder, AGT, AdvSys, ArcheType, ...

You don't need to write any Java code to be able to play games directly
from the archive. Netscape supports helpers. That's good enough.
It could even be better, if the Java won't let you save game states.

There are some security issues here, but I think that they can be worked
out, because the Z-machine could be adapted to a "security sand box"
that would allow file operations only as necessary.

Stephen van Egmond

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
In article <705uvt$48...@fido.engr.sgi.com>,

John Francis <jfra...@dungeon.engr.sgi.com> wrote:
>> It determines the URL based on the Internet address of
>>the browser's computer. So if you browse the Front from France, it gives
>>URLs to papers beginning with http://xxx.lpthe.jussieu.fr/, while if you
>>read it from the US, the pointers begin with http://xxx.lanl.gov/. If it
>>can't guess the geographical location of the browser, it defaults to LANL.
>
>A very nice idea. This could be done, today, to point to the GMD mirrors.

Indeed. I may just do it.

/Steve
--
,,,
(. .)
+--ooO-(_)-Ooo------------ --- -- - - - -
| Stephen van Egmond http://bang.ml.org/

Greg Kuperberg

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
In article <7086ul$6kh$1...@joe.rice.edu>,

Lucian Paul Smith <lps...@rice.edu> wrote:
>Here is where I most disagree with you. If you limit yourself to z-code
>games, as you seem to be doing, the "URN" of each game is: its name.
>That's it. *All* z-code games are in the same directory, just as
>(apparantly) all math papers are in the /abs/ directory at lanl.

None of this is true. Although it's true that most of the best games
are written in Inform (at least if you agree with "Baf's Guide"), I was
only discussing Z-code for simplicity and because I haven't installed
a TADS player. (My introduction to IF is through the RedHat Linux
distribution, which comes with XZip and Christminster.)

My impression is that some of the Z-code games are in the competition
directories at ftp.gmd.de, not the "zcode" directory. Certainly some
of the games have one version in one directory and another in the other
directory.

Actually it wouldn't matter one way or the other if the identifier
(or URN) of each game were numbers or letters. It's important for
the archive to date the game, but it doesn't have to be part of the
identifier. But my impression is that there has been no conscious
decision to support any kind of name or path or what have you as the
official identifier of the game. The archive's interfaces depend on
certain unstated assumptions that certain directory paths function as
reliable identifiers. This is an oversight.

Since you mention it, there is no "abs" directory at xxx.lanl.gov. A URL
such as http://xxx.lanl.gov/abs/math.DG/9810101 is interpreted with a
Perl script. "abs" is for abstract; the URL for the Postscript has "ps"
instead of "abs". There is a general confusion in this discussion between
several completely different things: A game's (or document's) name for
humans, ways that you might search/browse for it, its identifier (mostly
for use by software), its networked location, and its filesystem location.

>A lot of this would indeed be cool to see. A 'front end' for the archive
>would be a great boon for newbies, in particular, and even for veterans,
>if done correctly. As I see it, the potential front end should include:
>
>-The game title
>-The game author(s)
>-Some information about the game, be it genre(s) or capsule reviews
>-The ability to sort by any of the three above methods.
>-Links to longer reviews, if they exist.
>-The ability to download the game to your computer and play it.
>
>As I understand it, this is *exactly* what AdventureBlaster plans to be.
>And I'm all for it. It's for Win95 only, but, let's face it--that's what
>newbies will probably be running, anyway. And if it proved useful enough,
>I'm sure some fun-loving people would port it to the Mac, or X, or
>whatever.

AdventureBlaster reflects a lot of good thinking, some of it similar
to the existing features of the xxx archive system and other examples.
Its main drawback is that it is an indivisible solution to problems
that should be solved with independent components: The archive,
search/browse/review overlays, browsers, Z-code and TADS players used
as helpers for the browsers. (I've been discussing Netscape and XZip
just for simplicity, but people with telnet-only connections could just
as well work with Lynx + Frotz.) While AdventureBlaster would heighten
the demand for better infrastructure, it would contribute relatively
little infrastructure itself.

I have no idea if most "newbies" run Win95 or not. I don't. It should be
food for thought that Christminster is one of the most widely distributed
freeware IF games, just because it comes with Redhat Linux.

Stephen van Egmond

unread,
Oct 16, 1998, 3:00:00 AM10/16/98
to
In article <luNV1.5650$Ig6.1...@news.rdc1.on.wave.home.com>,

Stephen van Egmond <svane...@home.com> wrote:
>Indeed. I may just do it.

... and I just did. Redirections are now done to Australian (.au and .nz addresses),
Finnish, and German mirrors. All others go to ftp.wustl.edu.

Branko Collin

unread,
Oct 17, 1998, 3:00:00 AM10/17/98
to
On 16 Oct 1998 10:19:17 -0700, gr...@manifold.math.ucdavis.edu (Greg
Kuperberg) wrote:

>Volker's site fulfills the crucial role of keeping the games.
>Unfortunately, access to ftp.gmd.de is sometimes bad.

[a transatlantic problem]


>Access to wuarchive is also sometimes bad.

[a budget problem?]

I am sorry, but you're wrong: it is wuarchive that has transatlantic
problems. Are you by any chance American? :)

>Let me also point out that when you give a document an id number or a
>serial number, you generally give people the impression that you are
>archiving or otherwise tending to the document. In the case of the IF
>archive, this would be a good thing.

Why would that be a good thing? Why do you want people to get that
impression?

>Of all the web interfaces I have found for the IF archive, "Baf's
>Guide" is by far the most useful. Carl has has thought of most of
>the basic necessary components of a good archive browser. The main
>area for improvement is the primitive use of HTML. Stephen van Egmond
>has more attractive HTML.

I have been working with HTML for a long time, but the distinction
between "attractive" and "unattractive" HTML is one I have never made.
I guess you mean that the one site is coded in such a way that it
looks better on your system using Netscape Navigator (or whatever you
use) than the other site?

There has been discussion before about the way IF is presented to the
masses and I believe Volker has changed a bit of the structure of the
archive after such a discussion.

The assumption always is that in the current situation IF is not
'marketed' good enough, so that people who want to find out more or
are otherwise initially interested, get put off IF very quickly.

I am not sure I agree with that assumption. However, I do think IF can
be made more accessible. An interface to the archive could be
organised in such a way that IF first timers could be introduced in as
easy a way as possible to the artform. Think of a web form or e-mail
form that you can fill in, stating what games you want to dl or get
sent, what system you use and whether or not you are a first timer.
Then some piece of magic (a CGI script) can make a package for you
containing the game file and an interpreter for your OS, archived in a
format that is the most popular on your OS (LHA for Amiga, ZIP for PC,
SIT or Mac, etc.).

--
branko collin, bco...@xs4all.nl
a a de de de de een het the the the
(various artists, gesorteerd op alfabetische
volgorde)

TenthStone

unread,
Oct 17, 1998, 3:00:00 AM10/17/98
to
jac...@alumni.princeton.eud (Jacob Weinstein) caused this to appear in our
collective minds on Thu, 15 Oct 1998 10:22:40 -0700:

>> o The archive could encourage or require authors to provide source for
>> new contributions.

>You will not find a single game on the RAIF-POOL archive that does not
>have source. This has proven invaluable in uncovering plagiarism, because
>for every game written in RAIF-POOL, there are literally thousands that
>have whole sections of code duplicated.

I browsed to the RPA the other day and found the source for... that game
which won the RP Awards for 1997 (help, please). It turns out that one of
the scenes had almost exactly the same code as my masterpiece. Here,
look:

Martins: bar
location = outside city, near pond, near Dawson's Farm
traits = small busy sports
bartender = Hank
;

Hank: human
traits = stereotype
;

fetchHank: puzzle
score = 1
location = inside Martins
action = Hank says hello to me
;

All the punk did was change Martins to Malt Inn and Hank to Hal. It's
even still Dawson's Farm!

>> o The archive could be maintained with the explicit guarantee that the
>> games will be preserved and freely available in perpetuity.
>

>Well, I can ALMOST guarantee this. The only thing that could possibly ruin
>my near-perfect system would be if somebody actually, somehow, some day,
>wrote a game in RAIF-POOL. But I'm guessing we're all pretty safe.

Spider_and_Web: game
genre = alternateuniverse spy adventure
style = partialinterrogation
conclusion = philosphical
;

-----------

The imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us

TenthStone

unread,
Oct 17, 1998, 3:00:00 AM10/17/98
to
gr...@manifold.math.ucdavis.edu (Greg Kuperberg) caused this to appear in
our collective minds on 16 Oct 1998 12:50:26 -0700:

>Here brief comments on two conceptual sticking points
>that seem to be coming up repeatedly:
>
>In article <01bdf938$f07f47c0$LocalHost@jonadab>,
>Jonadab the Unsightly One <jon...@zerospam.com> wrote:
>>I should certainly hope [that id numbers would] only be symlinks.

>>I would *not* want to browse an archive by date.
>
>The id numbers have nothing to do with how you browse the archive.
>They make it easier to keep records. In particular, they would make it
>easier for software agents to add value to the archive.

Why, because they would constantly poll for what they know to be the
next number? That's an interesting way of doing it.

>No one browses books by their ISBN numbers either. But it's a good
>thing that ISBN numbers exist!

Really? I could care less about them.
Besides, as many people have said many times before, there's more
than just games on the if-archive. Much more.

>>Not a bad idea, no. I think somebody already made a
>>Java version of the z-machine, no? Of course, it might
>>be less than trivial to make Java versions of TADS,
>>Hugo, Alan, Adventure Builder, AGT, AdvSys, ArcheType, ...
>

>You don't need to write any Java code to be able to play games directly
>from the archive. Netscape supports helpers. That's good enough.
>It could even be better, if the Java won't let you save game states.
>
>There are some security issues here, but I think that they can be worked
>out, because the Z-machine could be adapted to a "security sand box"
>that would allow file operations only as necessary.

You seem to be confused on a point.
Netscape helpers actually have to download the file before they can do
anything with it. Your PostScript files are downloaded into cache and
then loaded. It has very little to do with server capacity. And the
savefiles would be on the local machine, although they would also be
worthless, since Netscape wuold overwrite the gamefile almost every week,
depending on Internet use.

I have no intention of setting up Netscape to download Jigsaw every time
I want to play it, just so that I don't have to set aside the hard disk
space. You see, that would involve entering Windows, loading Netscape,
downloading the file, and then loading jzip (or, more likely, some Win3
z-interpreter), and it's the stupidest thing I've ever heard. Yes, maybe
if I was only going to play it once; but I'm not. I probably couldn't
finish the whole thing very easily in one sitting even if I'd completed it
several times before.

Physics papers are very different beasts. Don't take this as
condescending, but archiving them is much simpler: you establish precise
standards (two files per paper: the document and the source, each in its
place and category. Those are assumptions that cannot be made about
IF. For the most part, gamefiles are compressed data, often including
mutiple files within each archive. Some games have source code; some
have walkthroughs.

Also remember that a collection of essays on physics and mathematics
is essentially a collection of information. The purpose of the IF archive
is actually archival: to store various files, utilities, and programs in
a convenient, centralized place.

Finally, most of us consider ourselves artists. Artists do not like to be
forced into change, especially by physicists (note that a great deal of us
do have extensive knowledge in the fields of physics and/or mathematics).
There are accepted routines which serve us well.

I mean, we could use a graphical engine with ifMUD, but why?

Angel Rivera

unread,
Oct 17, 1998, 3:00:00 AM10/17/98
to
TenthStone probably wrote:
> I mean, we could use a graphical engine with ifMUD, but why?

Mmm... graphical MUD... I was on a couple of MUDs with Pueblo support a
while ago. They're a good idea when used properly, but somehow having
images scrolling up the screen with the text just doesn't look right.
Having the background sounds was a nice effect. Having to click in the
text descriptions to go places wasn't, especially when that was the
*only* way to get commands to work. Also, some careless users forget to
shut off text formatting in their descs, which meant the rest of the
text coming in was either all italic, or 6 points too small, or...

Wait, what was the question?
:;walks off looking puzzled;:

--Muke!
--
He who dies with the most toys, is, nonetheless, still dead.

ICQ:1936556 http://mc11a.southern.edu/ -Personal [non-C1/C2] homepage
http://welcome.to/alt.binaries.games.creatures -Visit the abgc archive!

Magnus Olsson

unread,
Oct 18, 1998, 3:00:00 AM10/18/98
to
In article <36291587...@news.erols.com>,

TenthStone <mcc...@erols.com> wrote:
>gr...@manifold.math.ucdavis.edu (Greg Kuperberg) caused this to appear in
>our collective minds on 16 Oct 1998 12:50:26 -0700:
>>No one browses books by their ISBN numbers either. But it's a good
>>thing that ISBN numbers exist!
>
>Really? I could care less about them.

Just as a data point, I've actually searched for books by ISBN at
occasion, both in library databases and when on-line shopping.

However, if anybody ever thought of organizing a library by ISBN,
rather than by subject and author, I wouldn't want to use that
library.

Geoff Bailey

unread,
Oct 21, 1998, 3:00:00 AM10/21/98
to

In article <707v6l$p36$1...@manifold.math.ucdavis.edu>,

Greg Kuperberg <gr...@manifold.math.ucdavis.edu> wrote:
>
> After that, Netscape launched each game smoothly, which was good.
> Unfortunately, XZip made some incorrect assumptions about what I wanted
> to save. It let me save the state of a given game, but the default was
> pretty bad: /tmp/M03626A5D803E5D62.sav. It had no idea that I might
> want to save the Z-code of the game in my own directory (given that
> Netscape put it in a temporary directory to launch the helper).

No, you made incorrect assumptions about what XZip should do. XZip needs a
game file to play; since you provided this file you are capable of putting
it where you want - it is not XZip's job to do this. You should have used
Netscape to save the zcode to file (since it is Netscape's job) or copied
the already existing local copy of the zcode (/tmp/M03626A5D803E5D62) to
somewhere you found more agreeable. XZip does, however, need to save game
state, and this is a perfectly reasonable thing for it to do.

If I peel potatoes over the sink (so the insinkerator eats the peel) and I
drop a potato, I don't get upset because the insinkerator won't peel the
potato for me; I pick it up again and use the potato peeler.

[ The name is bad because of the temporary names that Netscape uses. If you
had followed the sensible course of using Netscape to save the zcode to a
useful name - such as "minizork.z3" - then the default save file would have
been the helpful "minizork.sav". ]

Cheers,
Geoff.

-------------------------------------------------------------------------------
Geoff Bailey (Fred the Wonder Worm) | Programmer by trade --
ft...@cs.usyd.edu.au | Gameplayer by vocation.
-------------------------------------------------------------------------------


Eric O'Dell

unread,
Oct 22, 1998, 3:00:00 AM10/22/98
to
On 16 Oct 1998 19:31:33 GMT, lps...@rice.edu (Lucian Paul Smith)
wrote:

>As I understand it, this is *exactly* what AdventureBlaster plans to be.
>And I'm all for it. It's for Win95 only, but, let's face it--that's what
>newbies will probably be running, anyway. And if it proved useful enough,
>I'm sure some fun-loving people would port it to the Mac, or X, or
>whatever.

Version 2 (for which thou shalt not hold thy breath ere the end of
winter) will be coded using the wxWindows v2 library, so porting it to
Mac and Linux should be relatively simple. I plan on doing the Linux
port myself; it may actually come before the Win95 version.

In the meantime, game authors looking for a way of making installation
less painful for the commandline-impaired are advised to take a look
at the freeware Inno Setup package, which is located at:

http://www.connect.net/jordanr/isinfo.htm

I'm about to upload a distribution of the IF-Comp games to GMD,
complete with interpreters, that was built using Inno.

Inno does allow you to check for pre-existing files, among other
things, so it might conceivably provide a standard tool for installing
games (at least for Windows) provided we could collectively reach some
agreement about standard install directories, etc.

>The URL for AdventureBlaster is:
>
>http://members.tripod.com/~abadger/ifmain.html
>
>Uh, I can't seem to find the guy's e-mail address, but I'm sure he'd
>welcome suggestions (and encouragement) for the version 2 he's working on.

Donations of C/C++ code for downloading files via http and ftp would
count as encouragement in this instance. <g>

--Eric


+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+

David Rush

unread,
Oct 23, 1998, 3:00:00 AM10/23/98
to

WRT http:// vs ftp:// and the if-archive

"Jonadab the Unsightly One" <jon...@zerospam.com> writes:
> David Glasser <gla...@NOSPAMuscom.com> wrote in article

> > Of course, don't forget that any good ftp client lets you sort by
> > date.

> Unfortunately, a lot of people only have Navigator (or worse, IE) as
> an ftp client. Maybe not a high percentage, especially among
> IF people (since this affliction is especially common among Windoze
> users), but there are such people. (I'm not bashing Web browsers,
> and I think it's great that they at least do allow access to ftp,
> but they're not the same as having an actual ftp client. Maybe some
> day they will be.)

The one thing that no-one seems to have mentioned is that with ftp you
*always* move the entire file from one filesystem to another. Using
http for downloads has left me with crap in the browser window *far*
too often. Ths crap, when saved to disk, frequently remains crap.

As far as ftp clients go, I use ange-ftp (emacs), command-line ftp,
and netscrape. Of these, I mostly use netscrape because it is
multi-threaded. I really hate watching the download light blink. Since
I'm usually chasing more than one file when I'm looking at archives,
this tends to make netscrape my *ftp* client of choice. Too bad its
such a resource pig.

david rush

Mark J. Tilford

unread,
Oct 25, 1998, 2:00:00 AM10/25/98
to
On 23 Oct 1998 14:01:42 -0400, David Rush <dr...@bellsouth.net> wrote:
>The one thing that no-one seems to have mentioned is that with ftp you
>*always* move the entire file from one filesystem to another. Using

Umm... what do you mean by the above sentence?

>http for downloads has left me with crap in the browser window *far*
>too often. Ths crap, when saved to disk, frequently remains crap.
>
>As far as ftp clients go, I use ange-ftp (emacs), command-line ftp,
>and netscrape. Of these, I mostly use netscrape because it is
>multi-threaded. I really hate watching the download light blink. Since
>I'm usually chasing more than one file when I'm looking at archives,
>this tends to make netscrape my *ftp* client of choice. Too bad its
>such a resource pig.
>
>david rush


--
-----------------------
Mark Jeffrey Tilford
til...@cco.caltech.edu

David Rush

unread,
Oct 27, 1998, 3:00:00 AM10/27/98
to
til...@ralph.caltech.edu (Mark J. Tilford) writes:
> On 23 Oct 1998 14:01:42 -0400, David Rush <dr...@bellsouth.net> wrote:
> >The one thing that no-one seems to have mentioned is that with ftp you
> >*always* move the entire file from one filesystem to another. Using
>
> Umm... what do you mean by the above sentence?

ftp's behavior as opposed to moving the file from the http server to a
browser's cache.

david rush

Reply all
Reply to author
Forward
0 new messages