On Thu, 23 Dec 1999, George Greer wrote:
> Oops, yes, I apologize. I don't know anything that could make that
> sequence, although wouldn't it break telnet specs if used on a
> non-accepting client? \n preceded by a \r, I mean.
I'm not entirely sure, but Mercs get away with \n\r. At the worst, this
would be, \n!\r!(...), or if that was a potential problem, \r\n!\r!(...),
as I don't believe there's any restriction against having an arbitrarily
placed \r in the input stream, provided that it's not part of a line-pair.
It doesn't much matter, however, since we're all in agreement that it's
stupid. I'd have to look more closely at telnet to determine whether or
not either of the above sequences is legal, but right now I should really
be finishing up my Christmas shopping. (At this point, it'd be better to
ditch my original replacement sequence all together and go for something
that we can be relatively certain doesn't have any strings attached,
perhaps \x1C...\x1C, which is nonprintable.)
> "c:\music\beep.wav" isn't very portable I'd say.[1]
According to the specification at http://www.zuggsoft.com/zmud/msp
absolute paths are illegal and you must use a forward slash. However, it
goes on to say that zMUD, which is the only implementation of MSP that I'm
aware of, accepts either a backslash or slash. This seems like it would
be problematic, since that means Muds may implement MSP using the
backslash and not notice any incompatibility. There's no mention (I saw)
of the backslash being deprecated -- although the best way to really
eliminate nonconformists is to break them and make the reason why common
knowledge. Even further, since a space is used as a delimiter in the
format, no backslash quoting ('\ ' to make a space) is specified, and no
whole strong quoting ("Wolves Howl") is specified, the filename space
suffers severe limitations, whereas many operating systems, those better
designed than Windows (from my point of view, of course; argue as you will
about GUI, etc., just not here), implement long filename support in a
transparent and clean manner.
> [snip stuff about placing sound files in the Windows Sound Manager]
Unfortunately, this isn't a silver bullet. First, Windows doesn't provide
user space security under most situations, so it's highly trivial for one
program to overwrite, remove, or change entries in the sound file manager
that your Mud might rely upon. This doesn't necessarily mean that some
malicious "hacker" (that is, cracker) is going to install Back Orifice on
your computer and replace all your sound files -- just that there could be
considerable conflict. Also, I don't know about the feasibility of
auto-downloading sounds into the manager -- I don't think it's possible,
but perhaps someone who uses Windows for actual development could tell me?
A better solution might very well be moving this sort of sound registry
into a per-Mud file with a CRC check, in addition to the client providing
a generic media store, so that individual Muds don't end-up creating many
duplicates of the same media file. The file could also be (optionally)
encrypted, and the client would be in charge of verifying the registry and
the individual files, alerting the server if the consistency checks fail,
and automatically retrieving replacements.
I invision something along the lines of people, not directly involved in
the creation of Muds, providing Mud content in the forms of media paks
that would allow the customisation of the UI and, indeed, user experience,
by simply replacing some of the Shared Media entries. I.e., I could
distribute the "Diku Media Pak" and have it shared. Security of the
registry against rogue Muds making alterations (or, even, user space
programs doing so) is probably best left for future discussion, as I've
already hung around much longer than I originally intended to.
-dak
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST