Clickable hubcommands in chat

[FlipFlop™]

As a variation on UCMD for rightclicks, i'm suggesting CHCM (Chat Hubcommand) for clickable hubcommands in a chatline.

This will enable the option to click on a 'link' in mainchat or pm which sends a command to the hub, similar to a rightclick command.

Examples:
- help-texts can contain clickable links to execute commands
- registration can be done by clicking a link in the welcome message and providing a password in the dialogbox

Context: F

Flags:
MS | Message(s)
LT | Link text, text to be highlighted and clickable
TT | The full text to be sent to hub, including parameters and keywords.

Multiple links can be put in one line, always a combination of LT and TT
Same client and user keywords should be allowed as for UCMD, with the exception that line:info is required, not optional.

Usage:
FHCM MSWelcome\sto\sthe\shub,\s LTclick\shere TT\s+regme\\s%[line:Password\\s(leave\\sempty\\sto\\sun-reg)]\n MS\sto\sregister

[FlipFlop™]

This might be more flexible if it can be used as extention to MSG:

FMSG +CHCM MSTo\sregister\s LTclick\shere TT\s+regme\\s%[line:Password\\s(leave\\sempty\\sto\\sun-reg)]\n
FMSG -CHCM To\sregister\suse\s!regme\s<password>

Then it should be usable in mainchat, personal messages, and chatrooms

[Crise]

Interesting proposal I would say, however, it does present a few concerns, well no more than a regular user command actually... how exctly would you present multiple linked commands in the same message though

[FlipFlop™]

Just by adding more LT<link text> TT<text including parameters/keywords> in the same line

Each LT will be displayed highlighted with the following TT as text to be sent to the hub, MS can be added anywere, except in between LT-TT. MS isn't required though.

[darkKlor]

An interesting idea, but is protocol extension a bit heavy-handed to achieve this goal, considering it's just intended as a chat message?

At risk of bastardising the format, I'd suggest you can use a custom Magnet URI to achieve the goal. It's perhaps not too great of a leap though, because URIs are commonly used as a method of refering to services e.g. the OData URI spec: http://www.odata.org/developers/protoco ... Components.

Such a URI would use the x. parameter prefix, as it is application-specific (http://magnet-uri.sourceforge.net/magne ... erview.txt).

An example, using the example in your 'Usage' section:
IMSG ABCD Welcome\to\the\shub,\smagnet:?x.ltclick+here&x.tt=%2Bregme+%25%5Bline%3APassword+(leave+empty+to+un-reg)%5D\sto\sregister

Here, the Magnet does not start until it is needed for the link.

NOTE: in this example I've www-form-encoded the raw TT message, rather than URI-encode the ADC-encoded message. A further note is that according to some sources (e.g. http://en.wikipedia.org/wiki/Percent-encoding, the method used by www-form-encoded is based on an early version of the URI spec (RFC1630 I think) in that it uses a + to encode a space, rather than %20. I've seen some suggestion that RFC3968, the latest revision, is more UTF-8 friendly.

[FlipFlop™]

Yeah, i've considered using URI since it's a chatmessage, but i preferred easier readability by using this extension.

This choice was also made for easy implementation: on clientside the parser for UCMD can be used for the TT flag, and on the hubside of things the UCMD generator can be used to generate the CHCM.

[Crise]

what is ADC's take on identically named fields in one message?

I would suggest having two named flags/parameters that contains all link words and all link texts in them (delimited by whetever you decide on), then you would parse the message doing lookup on the words in the parameter. Could be done as regular MSG command extension like this. using F type to send one with the extra info to those that support it.

[Pretorian]

what is ADC's take on identically named fields in one message

Perfectly fine, but you cannot assume the order of which the fields are interpreted.

[Big Muscle]

what about just adding html-like tags into message? It would allow something like <a href="open:pm"> or something like that?

[darkKlor]

Yeah, i've considered using URI since it's a chatmessage, but i preferred easier readability by using this extension.

This choice was also made for easy implementation: on clientside the parser for UCMD can be used for the TT flag, and on the hubside of things the UCMD generator can be used to generate the CHCM.

Okay, so I'm the hub owner and I want to create a MOTD. I go into a text file and enter 20 lines, or I go into a GUI and do it, either line by line or all in one box. Now I go and login via my client. If the MOTD is all in one text field, the hub is going to have to parse it and extract a section of text for the CHCM... presumably the entire line that the UCMD is on. The only option to prevent parsing is to force a field per type of input, but should the user have to care that they are inputting a line with a UCMD on it? Isn't the fact that you can insert it mid-line enough to suggest that it's just a normal message?

As for implementation, well I suspect extending Magnet parsing for two extra field names won't be THAT difficult. In fact, I think it should be a lot easier than handling a new protocol message on many clients. Hubs would need to add a magnet link generator of course, but then there's plenty of code laying around for that.