[93] in Coldmud discussion meeting

Re: ASCII Codes etc

daemon@ATHENA.MIT.EDU (Sat Dec 4 14:07:40 1993 )

Date: Sat, 04 Dec 1993 12:01:56 -0600 (MDT)
From: Lynx <BRANDON@cc.usu.edu>
To: coldstuff@MIT.EDU
X-Vms-To: COLDSTUFF

> The appropriate solution is to design a client-oriented, intent-based
> protocol, and then let people write clients to format the text however
> they want.  Line-oriented clients could punt and display everything
> without much presentation (VT could actually handle a little bit, such
> as emphasis and centering, given a real protocol instead of VT-100
> codes, which are a nightmare to parse out); newer clients could be
> more sophisticated.  For more references, see jtext.
                       				^^^^^
what/where/when/why/how

The thing is, I have no problem with using triggers for clients, but it has to
be easy for people to get their client setup to use them, not just some vague
'get an arr ceee file for it' which usually turns people off and they forget
about it.  I like things to look nice, I agree with your arguments for ANSI
codes, so lets make it easy to use other codes.

The only pro for using vt codes is that it is a KNOWN standard.  Far as I know
there really is not a very wide spread standard for anything else...

> Someone suggested reading in unprintables from the text dump.  I don't
> currently filter text dump input, so this is possible in 0.9.
> However, I will fix this hole in 1.0.

sure, great richelieu, there goes our chance to break everybodies clients :) 
(cant even do decent line animation anymore :(

> I am not going to try to place any injunctions on people against
> modifying the server, but I will not be at all pleased if people start
> using coldmud to output raw terminal sequences.

suuuure, set everybody up for a guilt trip.

> I will also not be
> pleased if people start handling multiple lines by sticking newlines
> in the text rather than using lists of lines.

that would be scary.

-Brandon/DragonLynx