0004145: Associate a `zan://` URL protocol to Zandronum and `ds://` URL protocol to Doomseeker

Notes
(0022870) WubTheCaptain (reporter) 2023-07-19 07:49	See RFC 7595, section 7.2 (BCP 35) for scheme registration procedures and Uniform Resource Identifier (URI) Schemes for the list. This intermediate step has not been done, but doing it is "strongly encouraged" according the Best Current Practice.

(0022871) duke (reporter) 2023-07-19 10:19 edited on: 2023-07-19 11:05	The problem with associating zan:// links directly with Zandronum is that in order to launch Zandronum to join a server, you need to: 1) Know which WADs the server has loaded 2) Actually have those WADs on your machine and know where to look for them Doomseeker solves both of these for you automatically, which is why I originally proposed to use it to handle the links. Could you elaborate on how you propose to handle this without using Doomseeker?

(0022873) Fused (reporter) 2023-07-19 12:55	You're right, one can only assume that the user has the PWADs specified to join the server. My application currently only supplies the join command, but I had plans to allow the files to be downloadable to an extend. Whilst not knowing if the files are truly downloaded, it's as far as we can go when it comes to sandboxed applications like this. I actually thought of providing both an option to start up either Zandronum or Doomseeker because of this, hence the proposal to have it work for either one.

(0022874) duke (reporter) 2023-07-19 14:04	Having the WADs is just one part of the problem. There is a big step going from a link to launching the appropriate zandronum command, and you didn't explain how that's supposed to happen. I understand that your app can generate the join command, but how does that help handling a link? Let's take an example. A user wants to join a server and clicks this link: 'zan://123.123.123.67:10666 [^]' What command does that launch? How exactly do you go from that link to launching eg.: c:\path\zandronum -connect '123.123.123.67:10666' -iwad 'c:\path\doom2.wad' -file 'c:\path\foo.wad' -file 'c:\path\bar.pk3' -file 'c:\path\baz.wad' My point is that it's not an issue of making an association. Zandronum just can't currently handle the link directly. To avoid launchers Zandronum would need some additional functionality, but you don't mention that.

(0022878) Fused (reporter) 2023-07-21 10:57	It is perfectly possible to pass all that data to Zandronum, but sadly the URI prefixes the command, and all the data will be encoded into something the URL can support. If we can patch Zandronum to detect if the data is prefixed with `Zan://`, we can determine if we should decode the additional data. Sadly, I'm not a C++ developer, so this is not something I can do. For the time being, I can only make my own protocol and patch the data into something Zandronum does understand. I can confirm that this does work after making a prototype.

(0022879) Fused (reporter) 2023-07-21 10:59 edited on: 2023-07-21 11:00	To support my previous note, and to add an example of the current issue, here is what currently happends: Assuming there is a valid registry key pointing to: `"foo\bar.exe" -connect "%1"` and you call this with: `zan:"127.0.0.1:10667" -iwad "doom2.wad" -file "foo.pk3"` the resulting string is: `-connect zan:%22127.0.0.1:10667%22%20-iwad%20%22doom2.wad%22%20-file%20%22foo.pk3%22` So if we can detect the format we could very much launch Zandronum this way.

(0022885) duke (reporter) 2023-07-21 11:55 edited on: 2023-07-21 12:23	Thanks for the clarification. The proposal makes a bit more sense if you assume that the links will encode the list of necessary WADs and that Zandronum will implement support for this. These are quite important assumptions that should have been mentioned in the ticket. Personally I don't find it very elegant, because there are servers with 20+ WADs, so the links would be huge, and users would still have to manually download the WADs. Also note that this isn't really in conflict with 0004015, even if 0004015 uses the zan:// prefix. You are assuming implementation changes in Zandronum, and this could be implemented in such a way that both Zandronum and Doomseeker can handle the same zan:// links. It would be up to the user to choose which app to associate. Doomseeker would auto-download wads and ignore the encoded info, while Zandronum could act as a "dumb" launcher for itself without the auto-download. EDIT: Actually there is a bit of a conflict, since Zandronum would presumably not be able to handle the short links with just IP and port (or the encoded info would be pointless). My bad.

(0022887) Fused (reporter) 2023-07-21 12:28 edited on: 2023-07-21 12:29	I'd like to change the initial suggestion. I realized from the other ticket that Doomseeker does in fact already support this scheme, and it would be a breaking change to change it now. Instead I would like the proposal to add `za:` for Zandronum to that it can be launched from a web application. Please note there is still the issue of the formatting the the prepending of `za://` in the url, which should be tackled. If somebody is able to change the title for me, that would be great. To answer Duke, as mentioned in the related ticket this is something for me to tackle, which I already did. This is not related to the ticket. It's not possible to associate `zan:` to both Zandronum and Doomseeker, and even if that happened it would be a very bad experience for the users to set that up. That's the whole point of the ticket. Considering Doomseeker already has support for `zan:` for over 11 years, I rest my case and think a change to the ticket is in order since it most likely won't change. That said, like I mentioned the big issue with associating a scheme for Zandronum is that Zandronum does not know how to make use of the passed url. There should be a way to determine if we are connecting using this scheme, and it should then be able to parse the url into a usable string. As I mentioned, I'm no C++ developer so I can only assume how it would work, so perhaps omebody is interested in looking into it. It would help greatly if this was possible.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	No one explicitly supports this issue yet.
Opponents:	DrinkyBird

Issue History
Date Modified	Username	Field	Change
2023-07-19 07:20	Fused	New Issue
2023-07-19 07:49	WubTheCaptain	Note Added: 0022870
2023-07-19 10:19	duke	Note Added: 0022871
2023-07-19 11:05	duke	Note Edited: 0022871	View Revisions
2023-07-19 12:55	Fused	Note Added: 0022873
2023-07-19 14:04	duke	Note Added: 0022874
2023-07-21 10:57	Fused	Note Added: 0022878
2023-07-21 10:59	Fused	Note Added: 0022879
2023-07-21 11:00	Fused	Note Edited: 0022879	View Revisions
2023-07-21 11:52	DrinkyBird	Relationship added	related to 0004015
2023-07-21 11:55	duke	Note Added: 0022885
2023-07-21 12:08	duke	Note Edited: 0022885	View Revisions
2023-07-21 12:23	duke	Note Edited: 0022885	View Revisions
2023-07-21 12:23	duke	Note Edited: 0022885	View Revisions
2023-07-21 12:28	Fused	Note Added: 0022887
2023-07-21 12:29	Fused	Note Edited: 0022887	View Revisions