On 29.01.20 04:16, Michael Conley wrote:
> Yes, standards introduction in our MUD community needs improvement.
My objective was not to start a discussion about the general process of this,
although I agree that there is no decent way.
Dear jof. That one... And MSDP... MSDP-over-GMCP... *sigh*
BTW: this transmission of data by cycling through TTYPE SEND/IS is obnoxious
(unless for cycling through different fallbacks).
Seriously: MSDP (Mud Server Data Protocol), GMCP (general
Mud communication protocol), MSDP-over-GMCP, EXOP (Telnet Extended Options
Standard), MCCP (Mud Client Compression Protocol, Version 1-3), MMCP (Mud
Master Chat protocol), MNES (Mud New-Environ Standard), MSSP (Mud Server
Status Protocol) und MTTS (Mud Terminal Type Standard)...?
> For example, something as simple as rows and columns, or ansi color
> choices, should be something that could be selected for the player at
> connection time unless they made an explicit choice otherwise.
I have to mention, that there is for a long long time support for exchanging
information about rows+columns of the terminal in telnet and it does work...
IMHO there is no need whatsover to duplicate that in yet another new protocol.
> Regarding Client.GUI and Client.Map, some may argue that to maintain some
> reasonable commonality that the package names should be kept the same
> across much of the code on the game side, while only the values would
> change game side depending upon the client being used for that connection.
Oh, no, no, no... IMHO: Someone who assumes using prior knowledge of the
server about the specifics of the client when answering questions from the
client is a sane design, likely thinks bathing in acid is a joyful experience...
Changing the response of the server for the same request depending on the
assumed (capabilities of) client is just mindbogglingly insane and crazy.
(Forgive me to use plain language, but I am really horrified that someone
would deliberately design a GMCP package like that, although it is not even a
real GMCP package in this case...)
If one implement GMCP (which one obviously does), one has a perfectly working
way for the client to request a specific capability, i.e. the correct one for
the client and the client decides what it wants.
There might even be a client who could interpret two different client packages
- why should the server know and decide what to send? Why should it maintain a
table of client names and versions?
> This would help us speak relatively the same language across the clients,
> motivating them to be more common, too.
The language is defined by the GMCP transport layer and it is always the same.
If different clients request to enable the GMCP package
"Client.<clientname>", they can perfectly share the same codebase. The spec
could also include additional data to be requested, e.g. different UI and map
formats for different versions if available.
Well, it is not client-specific and gets enabled by client request, thank you
for that.
Although I do not like the use of an empty message name making the message
basically the same as the package name in case of the Client.Media message.
This breaks the intended scheme in GMCP of organizing messages and packages
hierarchically (messages are always the leaves of the tree). The message
Client.Media would be the message "Media" in the package Client, whereas you
obviously intend it to be as message in the Client.Media package.