Comments (20)
from decky-loader.
I also think UNIX sockets is the way to go. Security aside, it's probably also the fastest and most low-overhead solution.
Regarding security, I'm not 100% sure how UNIX sockets work in detail, but a shared secret which is passed to the plugin server process via its environment variables could work? Would we even need to encrypt the traffic?
from decky-loader.
Remote Procedure Call would allow methods to be added to the API easily and there are already standard cross-language Remote Procedure Call libraries for communicating over UNIX or TCP/IP sockets. Another advantage is that If a plugin wants to add their own API that other plugins could use a RPC system would easily allow that. One option is gRPC which was part of the ProtocolBuffers project.
from decky-loader.
Work has recently started on support for websockets. Currently python is still needed to start up a plugin's custom backend written in other languages but once websockets are fully implemented, python will no longer be a requirement for interacting with the Decky Loader's backend.
from decky-loader.
I would say a Remote Procedure Call API over Unix Sockets is the best solution.
from decky-loader.
Hello, I found myself being blocked by the current back-end limitations and for what it's worth I agree with @ILOVEPIE and vote for gRPC.
from decky-loader.
This is something that's actively planned. It's going to be even better than explicit support of a specific language. it's going to be a system where any language where you can send information through a TCP socket will be supported.
I'll be closing this issue as this is planned to be supported.
from decky-loader.
Re-opening this issue to help foster discussion about how inter-process communication could/will work and usage temp Unix sockets vs other types as two examples of good points brought up by @JohnnyCrazy.
from decky-loader.
The loader already uses unix sockets under the hood, for IPC between the loader process and the isolated plugin processes, so in theory you only need to remove the python module run and add a subprocess to an external binary to do this. Most of the work regarding communication is already there
from decky-loader.
What are the advantages over the current solution with a barebones unix socket ? We only really use it for one thing and that is native plugin methods
from decky-loader.
Just throwing stuff in the air, but another completely different approach could be to allow loading of wasm plugins by integrating wasmtime runtime into decky-loader
https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready
from decky-loader.
The front-end is a browser so it's already got WASM support baked in. The best course of action would be to provide some sort of API to break out of the browser sandbox (safely) if Decky wanted to go that route. Adding another WASM runtime seems unnecessary unless the CEF version is too out of date or something (it's not; USDPL uses it fine).
But to actually touch on the central discussion: Decky already has support for custom back-ends, with USDPL being the only one that I'm aware of that's used by plugins. It's not using any standard like RPC, and only supports Rust back-ends atm, but it has zero reliance on Decky for back-end activities (aside from actually starting the back-end). The problem is communicating from the front-end to the back-end, and that can be solved just as well by third-party stuff so I don't really think it's necessary for Decky to have it. Obviously I'm biased because I am the third-party in this, but I think leaving it up to the plugins devs is the best course of action when there's no single obvious solution.
from decky-loader.
I would advise against using gRPC, you need to use HTTP/2.0 and protobufs have massive overhead vs a tcp socket
from decky-loader.
from decky-loader.
from decky-loader.
then couldn't a random path be passed to the plugin being started in the sysargs?
like /tmp/[some random string here such as a guid]
then the backend would be responsible for opening the unix socket and listening for event/some protocol between decky loader and plugins
from decky-loader.
Work has recently started on support for websockets. Currently python is still needed to start up a plugin's custom backend written in other languages but once websockets are fully implemented, python will no longer be a requirement for interacting with the Decky Loader's backend.
Clarifying, WebSockets are for communicating between Decky itself and the Decky frontend (and plugin frontends.) This does however solve one of the main things blocking custom non-py backend communication, since it will allow for bidirectional frontend-backend communication.
from decky-loader.
What about using a systemd service for backend services? Take the method used for running syncthing in game mode in this reddit post, and then have plugins communicate using HTTP requests or websockets.
from decky-loader.
Decky is already a systemd service, it can spawn custom backends. Installing additional services just makes it more annoying to uninstall
from decky-loader.
This has been largely accomplished through the custom backend effort some time ago. Closing.
from decky-loader.
Related Issues (20)
- [Request] More plugin info on store page HOT 3
- Failed Install - Steam Deck OLED - Never mind I'm an idiot HOT 5
- [BUG] No icon showing up HOT 13
- Support for BazziteOS (or a potential workaround) HOT 1
- Decky wants to "update" manually installed plugins wt higher version # HOT 9
- [Request] Identify and index plugins by package name, not plugin name
- [Request] Check Store Status HOT 5
- Decky Loader Store not loading HOT 4
- [BUG] decky loaded not working anymore HOT 24
- [BUG] Update to 2.0.16 causes popup menus to not appear in Steam Deck Game Mode. HOT 70
- [BUG] Wake from Sleep, Header info gone, games won't launch HOT 8
- [BUG] Failed to start plugin_loader.service: Unit plugin_loader.service is masked. HOT 7
- [BUG] Decky Loader can not (re)install or uninstall HOT 1
- [Request] Will Decky Loader work on SteamOS, Ubuntu, and/or Linux Mint. HOT 1
- [Request] plugin install progress HOT 4
- [ISSUE] Can't uninstall failing plugin, gaming mode broken HOT 1
- [BUG] Decky is broken on latest beta client. HOT 18
- [BUG] Decky causes Freeze on StartUp Animation HOT 5
- [BUG] Decky Loader causes Baldur's Gate 3 to crash shortly after launch HOT 3
- [Request] Make Decky-Loader compatible with Windows with Millennium Project HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from decky-loader.