-
-
Notifications
You must be signed in to change notification settings - Fork 826
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
standalone package? #742
Comments
Hm. As you mentioned, this would not allow for any customization out of the box, and the generated build output won't make for a good modification experience. However, it might be possible to produce builds that places in a Webpack shim that is run on bootstrap. Though this would require modification to the If something like this was to be done, I would probably prefer publishing it here on Github as a download that is generated with an Action or something like that 🤔 |
A release asset? That would make sense, yes: just download a zip file, decompress and publish with a static web server... Yes, that would work :-) I've just downloaded the code and followed the instructions at https://manual.os-js.org/v3/install/#setup, is the |
Yup!
You can add more discovery paths to
Since by default the packages built separately and only distributed as builds, this is required :)
It would "work", heh. But if the default configured theme is not either 1) statically included or 2) loaded with package discovery, everything would be kind of transparent in most UI elements. |
Not sure if consider it as a bug that should be prevented throwing an error, or a feature :-) What I miss for the discovery paths is to be able to define them in a |
Just a small addition to my previous comment. In the following issue os-js/osjs-client#106 (and any related linked in description), I have added support for the manifest stuff onto the server, because that's a requirement in order for user install-able packages to work. However, the package assets are loaded over the VFS. So it might be possible to expand upon that and actually proxy the package assets via the node server and "get rid of" the CLI package discovery (with exception of the standalone builds). Though this will probably have a bit of performance impact 🤔 |
If you're thinking about the source code in this repo, it's not really a modification of any of the core source. Think of this as a boilerplate. So you can just add Saying this, it could probably make sense to have some of this stuff exposed in dotenv by default 🤔 |
That was exactly the kind of architecture I had in mind for NodeOS (if I finally retake the project or not, that's another story...), GUI/Desktop being a static web app, and fetching the actual applications from the backend server or from other ones :-)
I think so, having the project working "as is", and having the "ad-hoc" configuration done by using a dotenv or a JSON file ourside the repo, similar to Linux kernel |
Now that you mention this... I think I actually was involved in a discussion relating to this in some issue for that project. Huh! 😄 I'll make a note on this and squeeze it into the user install update :)
The thing is, that the current distro boilerplate (this repo), is set up like this, but it's not a dotfile or a strictly JSON formatted files. I provided them as But having a dotenv to override the already defined configuration properties is a good idea. Not sure why I haven't done it here, because this is my default strategy for pretty much everything else. Opened an issue on this here: #743 |
Probably yes :-)
If it's a boilerplate, then maybe that's the reason: it's a template project intended to be modified, not a final one. More like "copy and adapt it to create your own OS.js", isn't it? |
And regarding to this and retaking our old conversation, my needs for NodeOS was a standalone static client web app with no login auth and using WebDAV for all filesystem accesses, including fetch of applications. Maybe a very customized version, so probably it would make sense to use this boilerplate to create an |
Indeed! I just realized, in order to automate the standalone distributed build easily, I basically have to add a Even though I don't need
I'm hoping to put in support for the latter in the next update with the user install stuff. The plan was to release it in stages because right now it's limited to the host filesystem only to prevent the client from doing too many requests in the discovery process (first locate all directories with an actuall app in it, then read the |
Then it was my fault for not understand it at first, I'm more into unifying efforts on "central" projects approach :-) Maybe add explicitly this focus on the docs?
I created some time ago https://github.com/piranna/unify-config, maybe it can be useful to you. You can define default values in the
Sure, WebDAV is just an extension to HTTP.
In NodeOS is done in two steps, first is by using https://github.com/piranna/nodeos-reverse-proxy to identify who's the user based on the same config of https://github.com/piranna/logon (that's available at https://github.com/NodeOS/nodeos-usersfs/blob/master/resources/logon.json) and redirect requests to his GUI server, that by default is https://github.com/piranna/davius. Davius is a WebDAV server, and its purposse is mostly to serve both the GUI files but also the apps assets and work as filesystem interface. The idea is that filesystem operations are probably 95% of what's needed, and if an app needs to do something that's not possible to achieve with a filesystem or resources and collections abstraction, then they would spin-up their own stateless servers, probably based on https://github.com/piranna/oneshoot (Davius is build on top of it), you can have more info at https://github.com/NodeOS/NodeOS/wiki/GUI. Apps servers could be able to register on nodeos-reverse-proxy by using https://github.com/piranna/nodeos-reverse-proxy-register, but I think I didn't created any of them yet... This was a long time ago and don't fully remember the details nor find the code about it, but I remember I though about using the name of the app server between brackets as the first element of the URL path to identify and route to it. Probably I didn't code it because didn't get too much advances on this area and was busy on other things, sorry. |
Yeah, it might not be clear enough :) I've made a few additions to the docs: os-js/manual.os-js.org@d06c2a8
The way I see it the
Yeah. And I looked into it and it seems like I can perform queries to cover my needs in terms of discovery. If only one could pull multiple files as well in one go. But I'll experiment with this.
Sounds pretty neat! |
Great, a lot more clear :-)
Does WebDAV support searches? I didn't remind of these part of the spec, but totally make sense, maybe I overlooked it. That would be great, not only returning files but resources, sort of like Windows where everything are "objects" (maybe more like Plan9, where everything are files and accesible using the filesystem). Can you point me to that searches/queries? :-)
Yeah, NodeOS was a lot of work... :-P But although I feel guilty of having it unattended and unmaintained, I'm very proud of it :-) |
https://tools.ietf.org/html/rfc5323 OMG, it does! That looks great! :-D Do you have someway docs of the actual OS.js internal protocol? |
I've read in the docs that's possible to build a standalone version of os.js without server, just only static content. Would it be possible to publish this "flavour" on npm, ready to install and use? Just only the generate the
dist
folder and publish it, and the same for the other ones... Obviously this would not have any customization, but could be used as basis, or allow customizations by other methods...The text was updated successfully, but these errors were encountered: