From DCppWiki

Jump to: navigation, search

This is an old proposal by Locate for the nmdc protocol (and below is a copy of his).


Name of the Feature: ViewportOptions

In the past, it has always been difficult to output data to the client in a well formatted form. With the different fonts and settings all the clients out there use, it was hard to post formatted lists of users, ips, bans, rules etc.. because the Tabsize may differ, the use of non-monospaced fonts or because of the difference of the character width between certain types of fonts. Another problem is the missing internationalization of the chat windows, there may be problems when people use different charsets (this is evident as soon as people start to use fonts with Kana support, while others still use the Windows default codepage to interpret the data). Displaying garbage in that case isn't a real alternative. I don't know how much is possible with with ADC at the moment, but if it's missing something like that it should be included as well.

Possible solution:

The hub may configure the clients viewport in a way that allows it to display different types of text. The problem is to assign the options to different windows (i.E. main chat, bot, PM chat with another users). There are two possible solutions for this:

  • The options are transferred before the first message from a certain users reaches the client. This is a PM sitation, a bot sends a message to user USER (with formatted chat data):
$SetviewportOptions BOTNAME USER +utf-8 +cp437 +pre|
$To: USER From: BOTNAME $<BOTNAME> This is Preformatted Text, utf-8, cp437|
$To: USER From: BOTNAME $<BOTNAME> And it still looks the same|
$SetviewportOptions BOTNAME USER +utf-8 +cp437 -pre|
$To: USER From: BOTNAME $<BOTNAME> This isn't preformatted anymore|

The client will configure the upcoming chatwindow in a way that allows him to display the data as expected by the bot deleoper. The problem is that this can't work in a transparent way if the hub doesn't support this at all (it would require a new command in the hub software, or the hub must be able to send raw data to users).

  • If the client indicates that viewportOptions are supported in its 'Supports', the command could also be encapsulated in the chat message itself, making it transparent for the hub. The sad thing is something that looks like a hub command is being sent in a PM. I don't think that would a good idea.


To be able to figure out what kind of options a client supports, the hub (or another use/bot) may send $GetviewportOptions BOTNAME| if the client seems to support the feature. BOTNAME is the name of the sender in that case. I think the BOTNAME info should be optional, as the hub or a directly connected user or bot may be the only ones who want to figure that out.

The client may answer with $viewportOptions USER <viewport options>|, <viewport> options being the current setting.

An exlaimation mark before a viewport option indicates that the option is not changeable on the client, for example:

$viewportOptions +utf-8, -pre, !+cp437, -ascii7

indicates that cp437 is supported, but not changeable. Preformatting is supported by deactivated. This may prevent that the hub changes the viewport in a way that is not desired by the user and makes it possible to give the client data it really understands.

Possible Options

List of possible viewport options (There may be a lot more of them, these are just some examples):

utf-8 Standard ASCII support. If the highbit of a character is set, it indicates that a non standard character is being sent. The remaining interpretation relies on the current codepage.

ascii7 Seven bit compressed ascii. There data in the chat message (everything that comes after the username tag) is only 7-bit wide per char. The | delimiter at the end of the message is 8-bit aligned. It could be possible to save some bandwidth with this, as long as the hub forces the use of 7-bit characters.

cpXXX The codepage XXX will be selected/deselected, whatever

vtXXX The client is able to emulate aspects of vtXXX terminals (vt100/vt120 come to mind here). Might be interesting to display hub or network logos, even colored ones.

$SetviewportOptions $HUB USER +utf-8 +cp437 +vt120 +vt110| <BOTNAME> ESC[31;42mohhh!ESC[0m|

If $HUB is being used in $SetviewportOptions, it indicates that this sets the style of the main chat window.

pre The text is preformatted, and should be interpreted with monospaced text. If it contains tabs, the tabsize should be configured correctly with the following option.

tabsizeXX The tabsize used to interpret tabs inside messages correctly.

sizeyXXXX sizexXXXX Size of the viewport

jjisXXXX JIS standard for the transportation of japanese characters, especially interesting in 7-bit mode

That's it. This looks still very crappy, but it is just something that might be a nice feature (maybe not in the same form, but it could work that way). To conserve bandwidth, short form of the commands should be available.

Related Links