4 ms·

You're right about the decoupling, and the key mechanism for doing that is a multi-process program model built on Web Workers. With small, independent programs

by pfraze 14y ago

You're right about the decoupling, and the key mechanism for doing that is a multi-process program model built on Web Workers. With small, independent programs populating the page, you gain versatility and reusability, as components can be swapped and configured by the user. Compare this to the monolithic client of one-tab/one-app, and you have the answer to the grandparent post's question. Because of the custom program model, Grimwire's concerns include program lifecycle, resource management, permissioning, peer connectivity, and UI toolset, so that's why we call it an OS.

marssaxman 14y ago
Got it. Sounds like you guys are actually building something I fantasized about while I was working at Google, while I grew steadily more disillusioned with their whole data-warehouse business model... Got any work for someone who has experience with large distributed systems but is basically allergic to frontend web technologies?
- pfraze 14y ago
  Yeah, no doubt we could use the expertise. Shoot me an email at pfrazee@gmail.com
- wesray 14y ago
  Heh, I'm sure a spot can be found ;)
altcognito 14y ago
This sounds a lot like an fancy iframe with a communications layer. How is it different? (this makes it sound worse than it is -- in truth, this sort of visible integration is interesting, but I'm just trying to understand exactly what problem you're trying to solve)
- pfraze 14y ago
  Good question. Iframes (currently) share the process with the parent document, making it possible to DoS the page. They're also bound to a single node in the page, whereas the Workers exist outside the lifecycle of the DOM elements (and can serve multiple areas of the DOM). The kind of gains we're looking for are the kind that you get out of unix's small programs and pipes. URLs are a fairly powerful primitive-- they can represent remote endpoints, local endpoints, and pieces of data (with data-uris). So, for instance, with some artful configuration/linking, you could have the same webapp write to local storage, remote storage, or the filesystem-- and make it easy for the user to choose, not with a premade choice, but with the ability to load software. Program-sharing can also continue the gains made by Ajax, where you can deliver programs to the client which understand a remote service's API. For instance, if my profile links to "send-pfraze-a-message.js", you pull that down and load the interface next to your files interface, drag in the file, then hit send. Then you load "send-pfraze-a-message.js" next to your strategy game interface, drag in a battle plan, and hit send. In both cases, your existing programs didn't have to understand whatever service I use to receive messages-- they just had to bundle data for click-and-drag.

by pfraze 14y ago

marssaxman 14y ago

Got it. Sounds like you guys are actually building something I fantasized about while I was working at Google, while I grew steadily more disillusioned with their whole data-warehouse business model... Got any work for someone who has experience with large distributed systems but is basically allergic to frontend web technologies?

pfraze 14y ago
Yeah, no doubt we could use the expertise. Shoot me an email at pfrazee@gmail.com
wesray 14y ago
Heh, I'm sure a spot can be found ;)

altcognito 14y ago

This sounds a lot like an fancy iframe with a communications layer. How is it different? (this makes it sound worse than it is -- in truth, this sort of visible integration is interesting, but I'm just trying to understand exactly what problem you're trying to solve)

pfraze 14y ago
Good question. Iframes (currently) share the process with the parent document, making it possible to DoS the page. They're also bound to a single node in the page, whereas the Workers exist outside the lifecycle of the DOM elements (and can serve multiple areas of the DOM). The kind of gains we're looking for are the kind that you get out of unix's small programs and pipes. URLs are a fairly powerful primitive-- they can represent remote endpoints, local endpoints, and pieces of data (with data-uris). So, for instance, with some artful configuration/linking, you could have the same webapp write to local storage, remote storage, or the filesystem-- and make it easy for the user to choose, not with a premade choice, but with the ability to load software. Program-sharing can also continue the gains made by Ajax, where you can deliver programs to the client which understand a remote service's API. For instance, if my profile links to "send-pfraze-a-message.js", you pull that down and load the interface next to your files interface, drag in the file, then hit send. Then you load "send-pfraze-a-message.js" next to your strategy game interface, drag in a battle plan, and hit send. In both cases, your existing programs didn't have to understand whatever service I use to receive messages-- they just had to bundle data for click-and-drag.