would it be possible to add server-client arch by adding full screen chrome as presentation layer? #13
Comments
|
You know I've been looking at slimmed down GUI options, like really small x-server, directFB, somehow running a browser directly on the framebuffer. Your idea is a lot more workable and simple, http and web sockets. This can both bootstrap initial gui efforts, as well as provide a quick path to remote hosted services. No xwindows. |
|
framebuffer chrome + xserver inside chrome, like https://github.com/GothAck/javascript-x-server |
|
I am confused, where is the Node OS code? |
|
I wish I knew more about x-windows and why or how it was useful, but I don't. So I can't speak to the benefits of what it does, but I'd imagine them to be drawing things that become windows or window like "stuff." Fonts, gui toolbars, etc. So, is it wrong to replace this with system with something completely wrapped around the GPU? For instance, an open gl/web gl like library which, from what I understand, talks directly to the GPU, not some window server, and re-implement things so they are offloaded to 3d processes? Overkill? Maybe. Reinventing the wheel? Surely. Again... my view is more fantasy than understanding reality in this realm. However, if we're talking about GUI and next gen, nobody is talking about webkit. Blink and servo are where people are looking. The servo project is abandoning legacy for future perf gains. Sounds like they're on the right track. Also, I'm really not in love with adding the web rendering layer just for the sake of dragging tag soup down to the command line for everything. There are so many better ways to write view logic. In fact, because this code wont be traversed by web crawlers, I'm struggling to understand the real benefits of having HTML's countless limitations bound to a new GUI which could be free of limitation. Just as food for thought, here's a link to servo: https://github.com/mozilla/servo/ |
|
I don't see the point of having any local gui at all. Does anybody envision using NodeOS as a desktop workstation? Why not extend and/or complement wssh/nsh with a client gui run from a browser. Experimental work in that direction could lead to some pretty great innovations in server configuration, monitoring, collaboration all via web. I mean, look at what Bootstrap accomplished for UI in such a short time. Why go the way of X11 with KDE or Gnome, with their microcosm of specialized developers and ancient esoteric legacies. |
|
This repo is definitely the right place to be discussing ideas like this, and there isn't really any serious idea too wild to be discussed. After all, we are trying to build an os off of node 👻 One of the reasons I wanted to do this project was that npm does a great job of being a package manager, so much so that the more I used it, the more I wanted it to be the entire systems package manager.
Re-inventing a few things like init is easy compared to re-inventing a community as engaged and passionate as the node/npm community. Fortunately, this means any package you decide to publish is a node-os package. Unfortunately this means the core of node-os will only ever be a small collection of packages. Anything that can be done through npm should probably not be in core node-os. I am not dogmatic about this view, and practicality/simplicity may dictate certain packages are included by default even though technically they could be omitted. Overall however, I want to keep the core distro small. I definitely can see people running faux-GUIs on node-os that are just webapps running on the server, but rendered in a remote browser. That is not to say trying to have node-os drive x11 though an HDMI interface isn't also on the table, node has great c/c++ support through npm/gyp. You aren't limited to JavaScript with node, I dive down into the c++ layer often. So I'd recommend developing your ideas as regular node modules. If they work on OSX/Linux, there is a good chance they will work on node-os. I am working on pre-compiling modules in #14 so don't be shy about getting your hands dirty with compiled/native code. Great discussion so far, please carry on! |
|
Yeah GUI support would be nice :) I would like to see a tool based on NodeOS where you can create a application for it and put it in a folder, add a startup image(to be showed until Node.js/Viewport is ready while booting, maybe have a function to call to hide the start screen when you're app is ready) and run a command to make a custom ISO. The OS would boot up a full screen browser Window running a Node.js app. No tabs, bookmarks, changing the url. All the OS would do is boot up to a full screen browser Window with a app running in it. I was thinking to make development easier, so you don't have to change the code and rebuild the ISO over and over. There could be a way to SFTP over your changed app and run a "respring" command. Also this OS would have a option to run from the CD/Flashdrive, and have a library to make it possible to build a installer and install this OS on there hardware. This libary would let you do the reformatting and copying over the required files. There would be a folder with the app where it would load from and then there would be another folder for userdata. Also since the backend would be Node.js based, there should be a way to disallow other people accessing the UI part from the network but the same OS could start a separate web server on port 80 for example, if the developer of the OS wanted to allow network accessible services. I'm guessing if the main startup app needs, then that app could download a upload named newapp.zip. Once download is done, call a function to tell the system that newapp.zip contains the updated app and reboot. Then the system would delete the "app" folder and create a new one containing newapp.zip contents. Then if the OS ever needed to change the bootloader picture displayed maybe have a another function to set that image. Well a module to interactive with this Node.js GUI based OS SDK. Oh and then there's updating the Node OS/GUI container itself. I guess triggering that can be handled by the same module too. Just a idea. I would really love to see something like this created. |
|
I would also love to see NodeOS be able to be used as a workstation OS, but being honest, it's more flexible to see it as a server (mainframe)-only OS and access to it and communicate from a standard web browser using WebSockets so later the interface can be adjustable, or maybe also using HTTP as a WebService. This has the advantage of being able to use several devices at the same time or also store the state on the server and keep running your session in other machine. In this aspect a good starting point would be to look at Plan9 or Inferno OSes and their P9 protocol, since they are already working on develop a Javascript+WebSockets based user interface. Nothing impide to serve the graphic components from this machine or other (they can be simple static CSS files), or also develop later a graphic stack (based on node-webkit and running with DirectFB+DRI2?) and run it from the same machine as X does. |
|
Hi, I have been playing with node-webkit (suggested by piranna) and I think it would be a good solution to use as presentation layer. The node-webkit runs in the same thread as node and as direct access to all node-modules. The advantage that I see in this approach is that all gui can be developed in html5 on top of existing node modules, and since the os is node based it would easily have access to most os functions. |
|
I don't believe that to use node-webkit "as is" would be a good solution to develop applications on NodeOS. It's a great tool, but I would not use it as a base framework as GTK or QT but instead use it just as an underlying commodity like X11, it's said, just as a HTML rendering engine. I believe that in this way, in the same way the HTML5 moto is "offline, mobile first" here at NodeOS the moto should be "online, remote first", so this way we can be sure that apps works both locally or in remote servers by design just as regular webs do, instead of only on the same machine as traditional desktop apps, so for this I would fully split the logic from the representation. In this way I believe makes more sense as a general graphic app architecture something like AppJS, where in fact the UI is in HTML. I'm not saying we need to force people to do them this way, i have been investigating about using WebGL or Canvas directly on the terminal this days, it's only that I believe that makes more sense on an OS like NodeOS that the apps can be used natively from inside a web browser from several simultaneous users without mayor problems and this being the native, easy, default way to do things, and the fact that you can use a local viewer (not need to be a local web browser, can be a degenerated one that only render HTML and little more, just as node-webkit does) to exec that apps "locally" would not make diference :-) In short:
Remember: remote first. Don't think you'll have a GUI anytime soon and think about your application (G)UI as an independent client project ;-) |
|
Well I didn't mean to say to use node-webkit as it is, I meant to say that is possible to integrate node with webkit as node-webkit does. I do prefer server-client arch, but that would need someone to develop a rest api or something like that. I also tried AppJS a long time ago it worked good but I heard there are several bugs with it... Anyway a server running a rest api it would be awesome ;) |
|
Yeah, I've seen the AppJS page and seems a dead project :-( But I definitely believe a server-client architecture is the way to go :-) The REST API can be up to the developer, there are several packages that make them easy. Only point would be regarding how to remotely connect to several apps on a machine. Ports? Paths? Each of this things has its problems... :-/ |
|
Just thinking loud: a service that create a webserver. When you connect to its root, it scan your user path for binaries and show a link to a subfolder for each one of them like an app launcher, and when going to that subfolders, that service launch that app and show you the app static HTML content. It would need to think about how to identify that valid apps, what to do with the ones that currently serve static content or dinamic one, if connect with REST or WebSockets... I think this would be a framework at the same level of GTK and QT or maybe also Gnome or KDE in the stack, so it should be left to others, isn't it? |
|
https://github.com/creationix/topcube I was thinking about something more like this: instead of a full, merged environment like node-webkit, just a launcher and render of HTML pages. There could be problems and issues with things like WebRTC and so (and more being several months without updates...), but being based on Chromium Embebed Framework ad node-webkit, app,js and Atom does and they have support for this features, it shouldn't be a problem, just a lack of features documentation :-) |
|
I think there is a few Web OS that simulates a desktop environment, not sure how they do it, but I think containing a app in a sandbox iframe (http://www.w3schools.com/tags/tag_iframe.asp) could do the trick, at least would prevent some issues. But I guess having a serious desktop as a web app can be challenging. Anyway the topcube seems a cool project. |
|
I forgot about iframes, thanks :-) Better than that would be FirefoxOS Browser API](https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API), that's an extension of iframe :-) Yes, there could be an "app" that works as a desktop environment (Gnome, KDE, ChromeOS Aura, FirefoxOS Gaia...) that manage other apps contained in iframes. The "desktop environment" could be entirely client-side and just manage to open new iframes and set their src attibute. [Ego mode=on] |
|
Hi, I also had been in company where we developed a intra-net based on windows and stuff like that. We also developed a single sign on auth system with kerberus, so users would be logged in with their system accounts (windows, linux, ...). I also made some experiments designing a website more like a OS (but not a OS), here: http://fsvieira.com/desktop/#about I think a good start would see what other projects have done in this area. But having a good architecture and let people build their own apps on top of it would be nice. Iframes are cool because lets you choose your own tools ;) Btw: I am sorry to ear that the company has closed. |
Spain is not a country interested in R&D :-( |
|
An interesting prospect is atom-shell by @zcbenz. I had the pleasure of talking with him at JSConf China last week. Atom shell has some very interesting stuff in it, and is pretty sophisticated. I had a look at how it builds on Linux, and it uses the GTK+ library. This would have to be built on another linux distro, and copied over, but it might serve as a working GUI layer. I haven't really dived into the detail since the GUI is the part I understand the least, but atom-shell seems pretty close to what you're looking for. Perhaps @zcbenz would be kind enough to weight in. Do you think Atom Shell can be used to provide the entire GUI experience of an operating system? i.e. no Gnome, no Window manager, etc. |
|
I don't know the internal details of Atom-shell, but what I have read about, it's purpose is somewhat similar to node-webkit. As I've said before, I would go for a less featured and more general solution so people is not tempted to "take a shortcut" and add Node.js specific code on the UI layer, something like Atom-shell but without the extras and Node.js interfaces added to the underlying Chrome Embebed Framework (more like in the topcube style). But yes, anything that's build on top of CEF or Gecko or any other high-level HTML renderer offer enough power to build an entire GUI experience, from a simple full-screen app up to a full-featured multiwindow desktop environment :-) Only things needed here is to be able to compile it and all its libraries to run on a terminal (no X11 nor Wayland here please, it's not necesary for our purposses and add complexity that affect to performance, just only EGL and nothing more if possible). |
|
Another alternative that I forgot to talk about, is webkit.js, the WebKit HTML renderer compiled to Javascript using Emscripten and capable to render WebGL and Canvas content :-) This can be another alternative to node-webkit and others, and probably require less binary dependencies (aka GTK) :-D Problem here is that we would loose the advantages of using a full browser environment as the ones based on CEF, so it would be something to consider, but I believe it would be a good starting point to move to more complex environments :-) |
|
I think the masses would be glad to see noGUI. Closing as this is inprogress in another thread. |
I think it would be interesting having html5 as presentation layer and OS access by connecting to local-host the node server, that way you could use a simple browser to remote access your nodejs OS computer.
The text was updated successfully, but these errors were encountered: