[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Plugins
. . -> [Subject]  trying to make atcp2 plugin to work
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: trying to make atcp2 plugin to work
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1  2 3  4  5  6  7  8  9  

Posted by Larkin   (278 posts)  [Biography] bio
Date Mon 02 Aug 2010 11:07 PM (UTC)  [ quote  ]
Message
Thanks for the details on the MXP spec. I did try to qualify my statement by saying that the implementations I've seen to this point have just been less than trustworthy, primarily IRE, and so now I'm not surprised to see the same sort of thing happening with GMCP.
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Mon 02 Aug 2010 10:04 PM (UTC)  [ quote  ]

Amended on Mon 02 Aug 2010 10:05 PM (UTC) by Nick Gammon

Message
I know that MXP is not defined in a RFC (at least I don't think it is) but per RFC 2119:

http://www.faqs.org/rfcs/rfc2119.html

This is the definition of "must":

RFC 2119 said:

1. MUST

This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 02 Aug 2010 09:48 PM (UTC)  [ quote  ]
Message
Nick Gammon said:
My interpretation of "you must use" is that choosing not to use a demanded representation should not be allowed. Otherwise it would be worded as "you may use".

I agree with your interpretation.

And yes, many standards are unfortunately lax in specifying precise behavior. I think it has to do with people treating any detail-oriented discussion as "annoying nitpicking". (Of course, the devil is often in the details, as you find out later after pushing through a protocol that ignores them...)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Mon 02 Aug 2010 09:29 PM (UTC)  [ quote  ]
Message
Seems to be a pretty common mistake. Shame on us MUD people for being so optimistic! XD
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Mon 02 Aug 2010 09:26 PM (UTC)  [ quote  ]
Message
You are right though that the spec basically describes how to handle the "success" situation rather than the failure situation. For example it is silent (as I recall) on what do to with:


<b


MUSHclient reports an error, but the spec doesn't say whether or not to do that.

Just as an aside the GMCP spec is somewhat similar ...

http://www.ironrealms.com/gmcp-doc

It describes what to do if you get, say, Core.Hello, but not what to do if you get Core.Foo (which isn't defined).

Similarly the telnet subnegotiation says that a subnegotiation sequence should look like: 


IAC SB x ... IAC SE


Putting aside the case of imbedded IAC IAC, it is silent on what to do if the final IAC is not followed by SE.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Mon 02 Aug 2010 09:19 PM (UTC)  [ quote  ]
Message
David Haley said:

My bad -- what the spec doesn't specify is what to do when the bracket is not escaped but not meant to be a tag. It doesn't say if it should be rendered, or discarded, or if an error should be thrown, ...


My interpretation of "you must use" is that choosing not to use a demanded representation should not be allowed. Otherwise it would be worded as "you may use".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Mon 02 Aug 2010 09:17 PM (UTC)  [ quote  ]
Message
Larkin said:

... but MXP doesn't account for that, or at least the implementations I've seen so far don't do it.


MXP does account for it, as I said above. And my implementation at the server end accounts for it as well:

http://www.gammon.com.au/mushclient/addingservermxp.htm

It is possible to make it work, but when an implementation gets into the wild which doesn't enforce the spec in this rather critical area, confusion has unfortunately reigned.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 02 Aug 2010 09:17 PM (UTC)  [ quote  ]
Message
My bad -- what the spec doesn't specify is what to do when the bracket is not escaped but not meant to be a tag. It doesn't say if it should be rendered, or discarded, or if an error should be thrown, ...
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Mon 02 Aug 2010 09:13 PM (UTC)  [ quote  ]

Amended on Mon 02 Aug 2010 09:14 PM (UTC) by Nick Gammon

Message
It does demand it:

http://www.zuggsoft.com/zmud/mxp.htm

MXP Spec said:

Since a normal < symbol is interpreted as the start of an element tag, you must use &lt; to refer to a less-than symbol directly.


(My emphasis).

The problem actually is that zMud and cMud (as far as I know anyway) don't follow the spec (in this respect).

Since they don't follow the spec, lazy MUD developers have got away with not sending < as &lt; and say "it works in zMUD so there must be a bug in MUSHclient".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 02 Aug 2010 08:56 PM (UTC)  [ quote  ]
Message
Quote:
I have avoided MXP like the plague because MUSHclient doesn't seem to like when you get non-MXP tags that seem to match the MXP format, such as our "guild secret" channels that are surrounded with angle brackets (i.e., <<Channel>> Person says, "Blah."). The codes being inline with the text means you then have to escape the text that appears code-like, just as HTML uses &lt; and &gt; to display < and >, but MXP doesn't account for that, or at least the implementations I've seen so far don't do it.

MUSHclient enforces tag escaping whereas Zugg's software does not, and it tries to guess at what was meant. This means that many MUD developers have been lax -- and have been allowed to be lax by zMud -- in escaping angle brackets. This is not really MXP's fault as a protocol except insofar as it does not, strictly speaking, demand that all non-tag angle brackets be escaped (even though this is really the only reasonable behavior).
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Larkin   (278 posts)  [Biography] bio
Date Mon 02 Aug 2010 06:31 PM (UTC)  [ quote  ]
Message
I was just postulating that the logic behind the start/text/end method may have been to reduce the duplication of data, even though there are other things already being duplicated. I have no idea what they were thinking when they made this whole GMCP thing, and it is a bit of a mess now.

I have avoided MXP like the plague because MUSHclient doesn't seem to like when you get non-MXP tags that seem to match the MXP format, such as our "guild secret" channels that are surrounded with angle brackets (i.e., <<Channel>> Person says, "Blah."). The codes being inline with the text means you then have to escape the text that appears code-like, just as HTML uses &lt; and &gt; to display < and >, but MXP doesn't account for that, or at least the implementations I've seen so far don't do it.
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Fri 30 Jul 2010 09:14 PM (UTC)  [ quote  ]
Message
If you are going to make a design criteria "don't send duplicated data" then you are going to tie your hands somewhat. Or "minimize the bandwith" likewise.

Surely, if a new protocol doubles your player base, you won't mind if the bandwidth, per player, increases by maybe 50%?

After all, if your primary goal is to reduce bandwidth you could remove colour codes and send everything in monochrome (that saves something like 5 bytes per colour change). But then you might *lose* players if you do that.

My other comment is, if you just want to "mark up" existing text, without duplicating it, then that is what MXP can do quite well. For example:


<chat> <channel> General </channel> <player>Nick</player> <message> says, "Hi there!" </message> </chat>


That lets you pull out various parts of the message without sending the whole chat message again in another format.

However you will note that the marking up itself takes quite a bit of bandwith (eg. you need <player> ... </player> ) and this method makes it harder to decide to display the chat message in another window.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Lasher   USA  (21 posts)  [Biography] bio   Moderator
Date Fri 30 Jul 2010 09:02 PM (UTC)  [ quote  ]
Message
Larkin said:

So, what do I gain from an ATCP packet with channel messages? Probably nothing at all.


There are two main advantages with OOB data for me:

1. The player doesn't miss important messages because they happen to be in a note editor or similar.

2. The ability to send data in a format that lends itself well to machine parsing without spamming said data to the screen.

The first of these benefits does apply to channel communication too, although on some MUDs may not be an issue depending on what type of 'quiet' modes that MUD has available.

Other than this, I would agree that there is very little value in GMCP channels vs just capturing the main output. There are other ways around it of course, such as a "send channels even when in note mode" config option.

[Go to top] top
Posted by Larkin   (278 posts)  [Biography] bio
Date Fri 30 Jul 2010 08:36 PM (UTC)  [ quote  ]
Message
There is precedent for duplicate data, primarily the prompt information. Enabling ATCP doesn't suddenly cause your prompts to disappear. For 100% consistency, ATCP should only ever supplement existing MUD text, not supplant it.

I use the configuration option in Lusternia that removes all newlines normally resulting from server-side wordwrapping, so that's not an issue. Color is also not an issue because triggers can already ignore that. So, what do I gain from an ATCP packet with channel messages? Probably nothing at all.

It's little issues like this that make standards groups go nuts, as we've all witnessed with this particular standard already. :)
[Go to top] top
Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Fri 30 Jul 2010 08:28 PM (UTC)  [ quote  ]

Amended on Fri 30 Jul 2010 08:29 PM (UTC) by Worstje

Message
Is it duplicate? The output text is likely modified by adding server-side wrapping to it, just to name something. The other part is that, assuming you do it on a line-basis, you still have mixed data on the same line. If you suggest putting the OOB messages as if they were some sort of styleruns... well, as I said before, you're using the wrong technology.

OOB = Out of Band. Not part of the main text stream, as to keep maximum compatibility and to 100% cater to the scripts that need to deal with said data. Once you base it on the output, there's stuff like different lines, ordering, wrapping which may or may not be intentional, and for that matter information that is totally spurious.

So is it necessary to double the information? In my eyes, no. Once you decide you don't want the stuff in the main text stream anymore, and in some sort of window, and decide to user the OOB messages for that, you can turn said channels off for that medium ICly as they're a completely seperately 'negotiated' affair.

Edit: So maybe that Comm thing needs another feature.... 'supplemental' or 'replacement', which says whether the messages ought to replace the standard text output, or be given as an extra thing.
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

29,532 views.

This is page 2, subject is 9 pages long:  [Previous page]  1  2 3  4  5  6  7  8  9  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]