brianmcmichael
commented
7 years ago What are the steps required to change OSC Connect to OOD Connect?
This is a pretty broad question, and depends largely on what we'd want the end result to look like.
Would the idea still be to provide a no-install solution? A version that can be configured for a site and compiled? An installable version with the host configuration included? I think any are possible, but it's really a question of how deep into the guts of this app we'd want a sysadmin to go to deploy it, or how generic we'd want it to appear to clients.
For a similar app that has been generalized, the branding would need to be updated, and a way to maintain the login host would need to be set. I'd imagine that a custom domain could be added to the settings and persisted in the Windows Registry, keeping it a zero-install app. At this baseline, generalizing to this level would be simple.
What are the assumptions the app makes (and those that are OSC specific)?
Assumption by the app that client hardware is running a 32-bit or 64-bit version of Windows XP or higher. The dependency applications (WinSCP, TurboVNC Client, Plink.exe) may have more restrictive system requirements. (Need to consult those docs)
Assumption by the app that server has a login node that is accessible via username/password (i.e. not Bastion). Also assumes that tunneling to the login node will open up access to the compute nodes.
The hosts are currently hard-coded into the application at OSCClusterController.cs. These hosts could be modified by a different site to alter the available login nodes. Currently, the first host in the array is the "default", although the app allows the user to select a different default host, which is then stored in the Windows Registry.
The Branding is currently OSC specific also. Strings and links are hardcoded to OSCBrand.cs. OSC specific images are embedded into the app and called from this class.
The URI scheme is currently osc://. See RegistryHook.cs
There is some additional OSC-specific code at VisualizationNode.cs This class exists as a filter to remap Vis nodes on Oakley and Glenn that have different external and internal domains. This code would not need to be modified as it only remaps on a match.
That's about it for OSC-specific assumptions.
What is a conceptual map of the current architecture of OOD Connect?
TODO. I'll make an image for this.
Where do files need to exist?
The app can be run from anywhere on the system, (although IE disallows "Open" from the IE download temp folder). If the app is run from a writeable location, a folder is created named "ConnectFiles" in the same directory. If the app is run from a non-writeable location, a new temporary folder on the sytem temp path is created and the helper apps are deployed to there. See FileController.cs. The individual apps each have their own controllers for handling the installation and process management. See SFTPControllerWinSCP.cs for an example.
How does it work with vncsim?
On the execution of OSCConnect.exe a hook is added to the Windows registry that registers a custom URI type. Currently the URI is osc:// and we also provide awesim:// URI support for backwards compatibility with the original design. See RegistryHook.cs
Once this hook is registered, it becomes available to the web browsers. Once the link is clicked, the browser launches the OSCConnect application at the last-run location with the URI as the command line arg. That's processed in CommandLineController.cs. Once processed, the app fills in those values and programmatically clicks the "connect" button.
How does "auto-updating" work?
Updating is not automatic. The app makes a request to the GitHub releases API and parses the json response at GithubVersionChecker.cs If a newer version is available than the current assembly, a link is displayed to the download path. (This path is included in the API response)
How is WinFTP and other applications put in use?
Each application has it's own controller that manages the installation and process management.
- SFTPControllerWinSCP.cs (WinSCP)
- TunnelController.cs (plink.exe)
- VNCControllerTurbo.cs (TurboVNC)
- ConsoleController.cs (PuTTY)
These classes have similar API signatures and should probably be inherited from an Abstract class for best practice, but they don't at this point.
Is it worth any consideration rewriting as an electron app or is that not even possible?
It depends on your intentions. Is the goal to make it cross-platform or for maintainability? If the idea would be to make it cross-platform, I'd switch it to Mono, since most of the same codebase could be used, it would have to be expanded on for process management on OSX and Linux. If the goal is long-term maintainability using web tools, I'm sure that it would be possible in Electron, but it would require a re-write. I don't have a lot of insight into NodeJS's client-side feature set, managing processes should be available as on the server side. I think it may require a feature pare-down. My initial concern is that I make a number of low-level system calls to Windows for various functions I want to perform. I've placed these calls into a single class to keep them in one place, available at User32.cs. Another interesting piece of code that I'm not sure will transfer is in the main Program.cs Where I extend a number of features from VB.NET that allow me to send command line arguments to a running process (here, the OSC-Connect application) without spawning a new instance of the application.
ericfranz
Questions to consider:
What are the steps required to change OSC Connect to OOD Connect? What are the assumptions the app makes (and those that are OSC specific)? What is a conceptual map of the current architecture of OOD Connect? Where do files need to exist? How does it work with vncsim? How does "auto-updating" work? How is WinFTP and other applications put in use? Is it worth any consideration rewriting as an electron app or is that not even possible?