3 ms·
Like maybe we can build this out. A common daemon for registering with. The concept would be very simple to build. I might start a github project. - Global da
by mbrumlow 7y ago
Like maybe we can build this out. A common daemon for registering with.
The concept would be very simple to build. I might start a github project.
- Global daemon to register apps with. Apps could be installed system wide or per use.
Think plopping a zip/tar/ or directory structure in something like /usr/local/webap.d/(namespace) -- might be abetter directory. Then a manifest file that describes some things about the service, such as how to start the API service, and the default entry point (index.html).
- The global service is responsible for bringing apps on line by way of instance activation on say visiting a name space, or just keep them running.
- Services once launched pick random port from range to bind to and system service acts as a reverse proxy and common auth for validating the local user. Maybe even ensure each of the API services are run per user and jailed to the home directory
IDK, just thinking off the top of my head, I have written bits and pieces of this for various work projects, but never glued the idea into one single system.
- spirodonfl 7y agoIt's not that hard, actually, I've done this with Node. Since you can install Node anywhere, include a binary, or whatever, you can have Node run as a server and it can run with elevated privileges, if needed. You have it scan a directory structure and auto generate a path that you can use in a browser, any browser, to view your newly install app. You can do this with APIs too so you can have internal tools with APIs via a Node server that do all kinds of things. Some simple port forwarding rules (ymmv) make this available to your LAN or to the WWW. Add a DNS layer on top and you have something really cool. I do this for all kinds of stuff, mostly PWAs, but it lets me have my own notes, todo, systems management and more.
- johannes1234321 7y agoIt is easy, till you get into the trouble of local Firewalls, Double use of port numbers and all those details, where the daemon runs unexpectedly or stops without good information to the user etc
- spirodonfl 7y agoThose can be solved
- mbrumlow 7y agoIn my minds eye we would give one dedicated port to the main service. The apps would pick a random unused port, and report back to the main service to which would then become a reverse proxy from the main services port to the bound port. So if the rsync app bound to 5392, it would report back to the main service so. And it would ensure all (or some subset of request) to rsync.localhost were reverse proxied back to localhost:5392. For the most part when I say some request I mean most if not all, but it might be nice to have a system level rsync.localhost/.info uri that would give system level information about the app.
- yjftsjthsd-h 7y agoIf we're on the local system anyways, why not just use an actual socket in the file system?
- zonidjan 7y agoIndeed; this also solves the problem of access control. Something like /tmp/notelectron.$EUID with umask 0077.
- mbrumlow 7y agoGood point, at least for the main service app communication. I would still want to maybe be able to reach my computers apps from a remote system.
- johannes1234321 7y agoSince requirement was "works with any browser"
- yjftsjthsd-h 7y agoYeah, but we're just communicating with the local proxy, right? So it'd be browser > HTTP over TCP > proxy > socket > application.
- raghava 7y agoCan containers better fit into this? Will it be better to couple it with a service discovery/publishing too (say consul, to make endpoints of multiple apps easily accessible)? Is there something that does this already, by any chance? (I might not have come across that!)