standalone package?

[piranna]

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...

[andersevenrud]

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 index.html file unless the client is modified to load a predefined script (if exists).

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 :thinking:

[piranna]

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 npm run package:discover step really needed? Seems it's only purposse is to search for apps and themes in the node_modules folder. Would it work (with an empty OS.js version without apps) to only exec npm run build?

[andersevenrud]

A release asset?

Yup!

is the npm run package:discover step really needed? Seems it's only purposse is to search for apps and themes in the node_modules folder.

You can add more discovery paths to src/cli/index.js in your distro. It works like this:

• Scan for any valid OS.js packages in predefined dirs
• Collect all metadata files
• Combine and output a manifest file
• Resolve and symlink all package dist/ directories into OS.js/dist/{type}/{name} (this can be copied as well).

Since by default the packages built separately and only distributed as builds, this is required :)

Would it work (with an empty OS.js version without apps) to only exec npm run build?

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.

[piranna]

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 .env file or some other external method, needing to modify the source code itself make me an itch in the back of my head... :-P

[andersevenrud]

Just a small addition to my previous comment.

In the following issue https://github.com/os-js/osjs-client/issues/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 :thinking:

[andersevenrud]

needing to modify the source code itself make me an itch in the back of my head... :-P

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 dotenv if you want and put that into the src/cli/index.js file.

Saying this, it could probably make sense to have some of this stuff exposed in dotenv by default :thinking:

[piranna]

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

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 :-)

Saying this, it could probably make sense to have some of this stuff exposed in dotenv by default

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 .conffile.

[andersevenrud]

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 :-)

Now that you mention this... I think I actually was involved in a discussion relating to this in some issue for that project. Huh! :smile:

I'll make a note on this and squeeze it into the user install update :)

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 .conffile.

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 src/server/config.js, src/client/config.js and src/cli/index.js -- and they're basically empty by default (just some small overrides for it to go into a "demo" mode kinda deal).

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: https://github.com/os-js/OS.js/issues/743

[piranna]

Now that you mention this... I think I actually was involved in a discussion relating to this in some issue for that project. Huh!

Probably yes :-)

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 src/server/config.js, src/client/config.js and src/cli/index.js -- and they're basically empty by default (just some small overrides for it to go into a "demo" mode kinda deal).

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.

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?

[piranna]

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 OS.js-NodeOS package :-) Just only, if it's a config issue everybody wins :-D

[andersevenrud]

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?

Indeed!

I just realized, in order to automate the standalone distributed build easily, I basically have to add a standalone: process.env.OSJS_CLIENT_STANDALONE or something like that.

Even though I don't need dotenv for that, it still probably would be nice to include it in some way. I'm not 100% sure yet :laughing:

using WebDAV for all filesystem accesses, including fetch of applications

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 metadata.json files). On the node server (and direct fs) it can just be globbed in one go. But now that you've brought this up I'm thinking maybe there's a way to perform a search or something like that on WebDAV and other types of storage solutions to get the same effect :thinking:

[piranna]

Indeed!

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?

Even though I don't need dotenv for that, it still probably would be nice to include it in some way. I'm not 100% sure yet

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 package.json file config entry and later people can define their customizations in .env files, or use something like https://www.npmjs.com/package/dotenv-webpack to make them more secure on client side code...

I'm hoping to put in support for the latter in the next update with the user install stuff.

Sure, WebDAV is just an extension to HTTP.

On the node server (and direct fs) it can just be globbed in one go. But now that you've brought this up I'm thinking maybe there's a way to perform a search or something like that on WebDAV and other types of storage solutions to get the same effect

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.

[andersevenrud]

Maybe add explicitly this focus on the docs?

Yeah, it might not be clear enough :) I've made a few additions to the docs:

https://github.com/os-js/manual.os-js.org/commit/d06c2a8d150c7c74a77689fd498a9547a8d37889

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 package.json file config entry and later people can define their customizations in .env files

The way I see it the config.js files covers exactly what one needs (and practically is the same as placing it in package.json, or; anywhere). But adding dotenv to override the default values in these files (for certain properties) could be useful so that one can both use environmental variables in command line, or the .env file.

Sure, WebDAV is just an extension to HTTP.

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.

In NodeOS is done in two steps, first is by using...

Sounds pretty neat!

[piranna]

Yeah, it might not be clear enough :) I've made a few additions to the docs:

os-js/manual.os-js.org@d06c2a8

Great, a lot more clear :-)

And I looked into it and it seems like I can perform queries to cover my needs in terms of discovery.

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? :-)

Sounds pretty neat!

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 :-)

[piranna]

Does WebDAV support searches?

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?