Closed lammel-hub closed 4 months ago
This would definitely simplify the usage of custom RVS. But I'm not sure if it justifies the effort for the implementation. I don't know if people even really have a need for this. Who has the motivation to run a custom RVS which has to be communicated to all parties - if there is one that can be used for free?
As always - thanks ,for your considerations of my ideas.
This and the two other remaining issues are actually my last suggestions, as it seems I cannot come up with any more potential improvements to this great software.There have been a steep development his past weeks and I am quite excited at how it has turned out!
Some context regarding this feature request is that I have setup a new permanent public RVS. This is my donation to the project and its users. You can test it by using tokenServerUrl: "https://dayon.helioho.st/rvs/"
.yaml
config opportunities more visible and user-friendly (as an example I was initially not aware of the autoconnecting to an IP address, which is quite a smart way to not need to depend on an external RVS at all. assisted.yaml
outside of the app).In the coming days I will look at the new web pages in Swedish and provide suggested adjustments to the wording (if needed),
Wow, thank you! An alternative RVS for redundancy surely is a great thing to have!
Concerning the .yaml
files, I'm not so sure if this would be the best way to go for the suggested integration into the user interface.
As all other settings end up in the .properties
files, which is also the standard way for Java application to persist their settings/parameterization while .yaml
files are very popular among cloud native apps. So I'll prefer to keep the .yaml
files "read only", just to offer a backwards compatible way to override connection related parameters.
To cut a long story short: I'll start implementing the integration into the UI as proposed, but will use the existing properties files to store the settings.
Excellent! As you have understood already, I do not know enough programming. Your suggestion is a perfect solution to getting it right!
Almost there
Assistant:
Assisted:
Looking great!
Q: the default box looks like it is editable.
Just to clarify my suggestion, just in case: I think it should be "read only" so the user always can revert back to it if needed.
Perhaps the default could be overwritten in .yaml
like before (for backward compaitibility), and then be visible there (i.e. if .yaml
contains "dayon.helioho.st/rvs/"
then that is visible in "default box" inside app)
Or perhaps .yaml
files are no longer needed with this enhancement?
Just a note, you understand all this so much better 👍
No, the default is "read only".
As it's implemented now, all functionality from the .yaml
files remains unchanged, thus it will still be possible to override "everything" by placing individual yaml configuration files.
The consequence of this is that the configuration from the yamls is (always) read and evaluated on start up. The user can adjust the connection settings, but these only last until the next start of the application if a yaml-configuration is in place.
I'd prefer to keep those two configuration paths as separated as possible, because it could quickly become confusing.
The primary use case for the yamls would be "vendored" instances, which should use a custom RVS by default. While the configuration via the UI would rather serve use cases, when the assistant instructs the assisted to use a specific RVS or to switch to another RVS due to an outage.
I didn't implement the "Do not use Token Server" option, because I thought that one can simply not use the feature, if he/she/it doesn't want to.
Thanks for the good explanation, makes a lot of sense ❤️
I think your clear thoughts on "vendored" instances would be great to have in the descriptive section for the .yaml
files (the "philosophy" behind them, not only the how-to)
Here is my suggestion (to save you the pain of updating the documentation) Quick start
section: "via configuration file" :
Configuring Dayon! using configuration file Since version v11.0.5, the connection parameters can be stored in a configuration YAML file.
This makes it possible to override user settings since the configuration from the YAML is always read and evaluated on start up. Users can make changes inside the application, but these only last until the next start if a YAML configuration is in place.
The primary use case for YAML configurations would for organizations that want to use a self-hosted token server instead of the public token server, or set specific host details and make assisted autoconnecting when started.
The structure of the assisted YAML is extremely simple:
host: "an.example.com"
port: 8080
# autoConnect: false
# tokenServerUrl: "https://example.org/token"
# tokenServerUrl: "https://example.org/token"
(Note: make sure to use the same as assistant)# autoConnect: false
The assistant also has a YAML configuration file.
# tokenServerUrl: "https://example.org/token"
(Note: make sure to use the same as assisted)The YAML file(s) can be saved under the name assisted.yaml and assistant.yaml either in the Dayon! home directory, in the user directory, or in the same directory as the .jar, resp. .exe file. This order also corresponds to the priority with which they are taken into account in the case of multiple configurations exist. (first one wins)
...and move the section "Automatic connection of the assisted" to the bottom of the page and rephrase it as follows:
Automatic connection of the assisted via command line The host name or IP address and port of the assistant can be passed via command line parameters, where ah=host or IP address, and ap=port number:
dayon_assisted.sh ah=example.com ap=4242
(Linux/macOS)
dayon.assisted ah=example.com ap=4242
(Linux Snap)
./assisted.sh ah=example.com ap=4242
(Linux Quick Launch)
java -jar dayon.jar ah=example.com ap=4242
(Windows/Linux/macOS)
assisted.exe ah=example.com ap=4242
(Windows Quick Launch)
If the assisted is started with these example parameters, it connects directly to the host "example.com" and port "4242".
Idea: perhaps add a new short section at the bottom of How to run a custom rendez-vous server (RVS)
Below you find a list of available public token servers that are free to use. Would you like to contribute and add your RVS to the list? let me know!
Check the availability of a token server by clicking on its link. If it shows the right version number it is active. https://fensterkitt.ch/dayon/ https://dayon.helioho.st/rvs/
Thanks again, I'll make those suggested changes as soon as I get to it. I was considering to shorten or split up the quickstart page, as it keeps growing constantly - but i have shied away from the effort so far. I already added the section to the README.md, but maybe the list of the available public token servers should also end up on the - you might have guessed it - quickstart page ;)
I like it!
Perhaps Quickstart could be reorganized (and split) as follows, as this would not require any new texts or images:
Note: the numbering etc. below is only to give you readability, I imagine regular headline formats etc.
section "Now you can ask the assisted to connect"
section "You're now connected and monitoring the remote computer."
add new sentence: "Note: If you are unable to connect by following the instructions above, you should check that you have the right settings
" (settings
=link to the suggested new page: Settings - see further down)
Managing the Session
(f) take screenshot of assisted (g) reset screen capture (trash bin), suggested: "the reset screen capture (trash bin icon) clears all cached screen data and reloads a new screen capture from assisted." (h) start an online meeting
section "Statistics Counters" moved from Support Page
Suggested new page: Settings (placed between Quick Start and Download in the Top Menu)
Assistant computer (a) screen capture config (b) compression config (c) connection settings (the new version you are working on) (d) Language (or inside Look & Feel? sorry, I forgot if it is coming back or was dropped)
Assisted computer (a) UAC settings (Windows only?) (b) connection settings (the new version you are working on)
Automatic connection of the assisted via command line (new suggested text earlier in this thread)
Configuring Dayon! using configuration file (new suggested text earlier in this thread)
Public token servers (new suggested text earlier in this thread)
To keep the number of web pages down, simply delete the web page Feedback and adjust the opening statement on the web page Support as follows (if you like it)
Your feedback is more than welcome! Post your question or open a new issue on GitHub.
UI2024: connection settings
I just realized that since .yaml
files overwrite any user settings this would be good to let the user know:
Perhaps when starting the connection setting function in the app, it should check if it finds any .yaml
files in the designated folders.
If it does, it would show a pop up window stating something like "Warning: a configuration file has been found. Any changes made will only last until the next start of the application."
(I believe this would reduce frustration for users that have not read those YAML sections online before using the app.)
Well, I started restructuring the quickstart and settings pages. But it will take some time until it's done. While going through the lines, which in some cases are more than 10 years old, I even spotted a minor bug: the counters don't have a strictly deterministic order :)
Good that they get a rework then. Thanks for your efforts!
UI extensions is included in release v14.0.0, the restructuring of the documentation is ongoing.
Is your feature request related to a problem? Please describe. The use of
assistant.yaml
andassisted.yaml
is a simple and elegant solution to user configurations. However, today it requires the user to download the files from GitHub, place them in an appropriate folder and edit them separately from Dayon!Describe the solution you'd like A simple interface to edit contents of
yaml files
. It should enable users to easily revert to default token server and to enable/disable autoconnect. Possible approach in three steps:Include the two
yaml files
in the installation package, in folder.dayon
(easy to access for all OS), instead of users downloading them separately from GitHubAssisted UI:
assisted.yaml
if pressing OK.Assistant UI:
assistant.yaml
if pressing OK.Note: to reduce clutter/fewer buttons for both users, the suggested option "do not use token server" would be used. It hides the token button (for Assistant - context Connection) and the token tab when connecting (for Assisted - after pressing "play button").
Describe alternatives you've considered
Additional context![image](https://github.com/RetGal/Dayon/assets/145585121/54eedba2-f44e-4869-a236-b6857f506cbb)
![image](https://github.com/RetGal/Dayon/assets/145585121/2fe00471-e0ca-4c66-8d52-018748aa64b0)