Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support telnet:// links #689

Open
vadi2 opened this issue Mar 31, 2017 · 19 comments · May be fixed by #3131
Open

Support telnet:// links #689

vadi2 opened this issue Mar 31, 2017 · 19 comments · May be fixed by #3131
Assignees

Comments

@vadi2
Copy link
Member

@vadi2 vadi2 commented Mar 31, 2017

Idea: MUDs should be able to provide an easy to use link with their connection info to spawn Mudlet and get it to connect to their game. Similar to apt://, steam:// and so forth links.

I think Mudlet should support those types of links - it'd be a lot more convenient for players to try out new MUDs if they only have to click on a link, instead of copying the server and port, going to Mudlet, making a new profile and so on.

As for the naming of the link, we could either go with a custom one: mudlet:// or - use an already standard one (telnet://), which would be much better as some websites use it already (http://dmud.thebbs.org/lotflink.htm) and it would be compatible with other MUDs clients.

I believe the latter option is better.

Telnet links seem to work in the format of: telnet://[:<optional port #>], see https://tools.ietf.org/html/rfc4248 for the actual spec.

The logic for this could be the following:

When Mudlet is spawned via the telnet link, check to see if any profile(s) server matches server field of the link. If multiple profiles do, auto-load the latest profile used. If one matches, load that profile. If not profiles match...

Create a new profile with the given server and port data, and the profiles name will be the servers name as well. Auto-load this newly created profile.

I think these cases sound plausible. There'll an issue with peoples already made profile using the server name vs IP address directly as webmasters might, but that's not something that could be easily avoided.

Launchpad Details: #LP1187243 Vadim Peretokin - 2013-06-04 04:47:05 +0000

@vadi2 vadi2 added the wishlist label Mar 31, 2017
@vadi2

This comment has been minimized.

Copy link
Member Author

@vadi2 vadi2 commented May 30, 2017

Quite a few of the MUDs I'm seeing use them. Going to compile a list here so we've got a bunch of links to check against:

http://www.durismud.com/

@Kebap

This comment has been minimized.

Copy link
Contributor

@Kebap Kebap commented Jan 17, 2019

Windows: Looks like you mostly need the installer to insert something into the registry. See https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767914(v=vs.85)
Linux: ?
MacOS: ?

Unsure what happens in Mudlet after clicking the link, in regards to Mudlet profiles.

@vadi2

This comment has been minimized.

Copy link
Member Author

@vadi2 vadi2 commented Jan 17, 2019

Yep. If someone could help design how this should work, that'd be a big help! Don't have to code it.

@druuimai

This comment has been minimized.

Copy link
Contributor

@druuimai druuimai commented Jan 17, 2019

@Kebap I'm not sure if this one is particular only for ubuntu/gnome and can be used by kde as well..

URL handler for linux

@Kebap

This comment has been minimized.

Copy link
Contributor

@Kebap Kebap commented Jan 17, 2019

So, let's just assume for a second, we do indeed succeed on all operating systems, and Mudlet will know when a user clicks a telnet link.

Now what should Mudlet do exactly? Here is a design proposal:

image

Open questions:

  • Do you agree on handling the different cases when one or more profiles are found?
  • Are there maybe even more relevant cases to check for, which I did not include?
  • Can telnet links also contain user name and password like mailto or ssh links?
  • Do we need option to disable Mudlet grabbing all telnet links, if users want to open links via telnet without Mudlet as well?

You can edit and build on top of this proposal online here (no registration needed)

@mpconley

This comment has been minimized.

Copy link
Contributor

@mpconley mpconley commented Jan 17, 2019

How about a question on startup of Mudlet for supported platforms like "Would you like Mudlet to be your default telnet client? Telnet is the most common protocol to connect to games through Mudlet." Cancel | Yes as options. Only ask on the first startup per version perhaps? Add some way to pop-up in the menus? Ideas to mold here.

-Tamarindo

@keneanung

This comment has been minimized.

Copy link
Member

@keneanung keneanung commented Jan 17, 2019

I agree with Tamarindo about letting the main Mudlet application set the URI scheme handler for two reasons:

  • We have installer-less versions of Mudlet (Linux AppImage, macOS .dmg) and making our windows installer do additional steps might be painful as well.
  • If the user set a different program to handle telnet links, they have no easy way to set it back to Mudlet.
@SlySven

This comment has been minimized.

Copy link
Member

@SlySven SlySven commented Jan 17, 2019

We do need to revamp the command line argument handling to provide a mechanism to accept the following arguments to make this work I think - so, in addition to the current limited arguments (the QT ones and -h/--help, -v/--version and -q/--quiet) I think we need to handle additional arguments:

  • a server URL
  • a port number (default to 23 if omitted)
  • an (optional) profile name - which is of limited use in resolving telnet:// scheme URLS but would help in, perhaps creating Desktop shortcuts on several OSes.
  • an (optional) character name to use - again, only really useful for creating a Desktop shortcut to a favourite profile (handling a password on the command line is awkward though, as it will likely be readable via system overview processes - e.g. top on *nixes)
  • a Boolean or something to handled the newly added SSL connections
  • a Boolean or something to enabled the Discord integration with the new/selected profile
  • a Boolean to suppress the automatic loading of profiles that are already marked to auto-load - currently autoloading happens, well automatically but there may be occasions (like resolving a telnet:// scheme URL) where this is not wanted

All but the last one ought to be allow multiple times to allow multiple profiles to be started - perhaps using the Server one as the delimiter for all the arguments following it until another Server one is encounter on the command line...

@vadi2

This comment has been minimized.

Copy link
Member Author

@vadi2 vadi2 commented Jan 17, 2019

What is the 'review all profiles' section? Does that encapsulate the logic that's shown after, or is it a separe pre-step?

@Kebap

This comment has been minimized.

Copy link
Contributor

@Kebap Kebap commented Jan 17, 2019

It is supposed to encapsulate and mean: Do this logic repeatedly once for every profile listed

@vadi2

This comment has been minimized.

Copy link
Member Author

@vadi2 vadi2 commented Jan 17, 2019

I like it a lot, here's my revision:

revised mudlet telnet___ handling

I took out the separate handling in case a user already has a username - I think we should connect with the unique profile. If it has a username, it just means the person can login right away and are familiar with the game.

@SlySven

This comment has been minimized.

Copy link
Member

@SlySven SlySven commented Jan 17, 2019

As for feeding the information from the OS into the call to start/connect with Mudlet I guess it should handle either the host/port or a profile name - the and case is not actually going to be helpful because if you have the latter the former is redundant...

Oh, how do we prevent the user from having multiple instances of Mudlet running at the same time - so that we do not spawn a second instance if there is one already open - in an OS independent and other users on same system - manner?

I feel as though we are about to be run down by a 🚌 possibly the QtDBus...

@vadi2

This comment has been minimized.

Copy link
Member Author

@vadi2 vadi2 commented Sep 27, 2019

👋 getting back to this as a lot of other work is waiting reviews.

@Kebap what is your take on my simplified #689 (comment) ? I think it'll be a more seamless user experience because less will get in the way of you actually playing.

Do you agree on handling the different cases when one or more profiles are found?

In general yes, see revision above. What's your take on it?

Are there maybe even more relevant cases to check for, which I did not include?

I think that is all of them 👍

Can telnet links also contain user name and password like mailto or ssh links?

It would seem yes! https://tools.ietf.org/html/rfc4248 We can support it.

Do we need option to disable Mudlet grabbing all telnet links, if users want to open links via telnet without Mudlet as well?

Yeah...

@vadi2

This comment has been minimized.

Copy link
Member Author

@vadi2 vadi2 commented Sep 27, 2019

#689 (comment): I see what you're saying but looking at the RFC, I don't think any of the suggestions apply to this specific improvement - rather as you mention, it's much more suited for desktop shortcuts and such.

@vadi2

This comment has been minimized.

Copy link
Member Author

@vadi2 vadi2 commented Sep 27, 2019

Are there maybe even more relevant cases to check for, which I did not include?

Update as I started working on this: this doesn't consider what to do when a profile is setup for auto-load, where in that case there's no need to bother the user with a connection dialog... 🤔

@Kebap

This comment has been minimized.

Copy link
Contributor

@Kebap Kebap commented Nov 5, 2019

Your revision seems fair. We can always add that gateway you removed if an increased desire arises...

If autoload is activated, I don't think I would expect a different result from clicking on a specific link. Autoload should probably be ignored in that case. Only if Mudlet is invoked without clicking telnet:// anywhere, then autoload should be honored.

@vadi2

This comment has been minimized.

Copy link
Member Author

@vadi2 vadi2 commented Nov 5, 2019

Yeah.

I've made good progress on this, but I got stuck on - if I remember right - actually registering Mudlet as an application handler. It's super unclear on how to do that in macOS and Windows, so if anyone has concrete steps that work, I'd love help in this.

@Kebap

This comment has been minimized.

Copy link
Contributor

@Kebap Kebap commented Jan 20, 2020

I found these summaries from Nov 16. Testing on Win 10 seems legit. There's also Mac and Linux:
https://support.shotgunsoftware.com/hc/en-us/articles/219031308-Launching-applications-using-custom-browser-protocols
They talk about adding a new handler, but you would need to inspect and update the existing telnet handler instead.

@vadi2

This comment has been minimized.

Copy link
Member Author

@vadi2 vadi2 commented Jan 21, 2020

Thanks a lot! I'll have a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.