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

Expand Protocol: Syncplay URN #264

Closed
Slider-Whistle opened this issue Dec 1, 2019 · 5 comments
Closed

Expand Protocol: Syncplay URN #264

Slider-Whistle opened this issue Dec 1, 2019 · 5 comments
Labels
enhancement help wanted Anyone willing to help can fix/implement this

Comments

@Slider-Whistle
Copy link

@Slider-Whistle Slider-Whistle commented Dec 1, 2019

As per the IRC URI scheme (https://en.wikipedia.org/wiki/Internet_Relay_Chat#URI_scheme):
syncplay://<host>[:<port>]/[<room>[?<maybe password?>]]

Also, I think that a default room (configured as a server property?) and port might be a good idea, so a user can enter just the command syncplay "sync.example.com" and immediately be in the correct room, which would be ideal for self-hosted, single-channel servers.

@Slider-Whistle Slider-Whistle changed the title Expand Protocol: Syncplay URI Expand Protocol: Syncplay URN Dec 1, 2019
@Et0h
Copy link
Contributor

@Et0h Et0h commented Dec 1, 2019

A Syncplay URI/URN scheme seems fine if it works on all platforms. If someone wanted to code it then it could be a nice discrete project for them, but at least for now I've not got much time for Syncplay development.

Having a default room is something that could work for private servers, but isn't something I would want to see on the public server. However, if you know enough to know which server to join then you will also know which room to join, so it is not essential - and on private server without room isolation enabled you can see what rooms are currently in use and join them easily enough.

@Slider-Whistle
Copy link
Author

@Slider-Whistle Slider-Whistle commented Dec 7, 2019

I know programs can register new types in Windows as long as they use some kind of installer (in this case, I guess it'd either be a commandline option to make one or an .exe would get bundled in), and on Linux distributions with XDG-compliant programs. I think Chrome and Firefox handle URIs and what programs to open them with theirselves. It's basically a shortform for the address and what options you want too, so being able to type "program programurl" is pretty much as good as being able to click a link/shortcut (does anyone use shortcuts these days?) to open the program.

I don't necessarily want all of these dumb, demanding ideas implemented immediately, I just wanted to see whether they'd be okayed, or if they go too much against the spirit of the protocol, in case some other hypothetical figure decides to implement syncplay from the ground up. Sorry for the late responses.

@Et0h
Copy link
Contributor

@Et0h Et0h commented Dec 9, 2019

If it needs some kind of installer then that does result in a two-tier system for those using the portable version of Syncplay.

@Et0h
Copy link
Contributor

@Et0h Et0h commented May 16, 2020

Given the complexity of making this work cross-platform and with portable versions of Syncplay I do not think this would be a good fit for Syncplay. If in the future someone can figure out how to do it across all platforms and versions of Syncplay and are willing to do so then let me know. For now I have added it to https://syncplay.pl/about/ideas/ under the heading of "Probably adds too much complexity to be worth it".

@Et0h Et0h closed this as completed May 16, 2020
@daniel-123
Copy link
Contributor

@daniel-123 daniel-123 commented May 24, 2020

For future reference, I found how it could be implemented on Linux: https://unix.stackexchange.com/questions/497146/create-a-custom-url-protocol-handler

@daniel-123 daniel-123 added the help wanted Anyone willing to help can fix/implement this label Mar 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement help wanted Anyone willing to help can fix/implement this
Projects
None yet
Development

No branches or pull requests

3 participants