Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
"Whose?" white horse 112 1:19pm ring a bell? On Oct 1, 2016 1:19 PM, "Marshall Conover" wrote: > > I was browsing of my old plan 9 mail and this conversation from 2000 > made me think of your thread here: https://goo.gl/PO85oD > > That conversation was interesting! It seemed Matt was a pretty prescient > guy. The "supports the latest standards...whose?" bit gave me a chuckle. > > There wasn't too much in the way of directed conversation about what > different implementations of the web could've been, sadly, though there > were some - more just how feasible it'd be to implement the web as it was > on plan 9. I'm sure whatever Rob's intern was working has been lost to time. > > Thanks for finding it! > >
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> I was browsing of my old plan 9 mail and this conversation from 2000 made me think of your thread here: https://goo.gl/PO85oD That conversation was interesting! It seemed Matt was a pretty prescient guy. The "supports the latest standards...whose?" bit gave me a chuckle. There wasn't too much in the way of directed conversation about what different implementations of the web could've been, sadly, though there were some - more just how feasible it'd be to implement the web as it was on plan 9. I'm sure whatever Rob's intern was working has been lost to time. Thanks for finding it!
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
Oh, and for anyone who hates web pages but were on the mailing list back then, it is the "[9fans] Gecko based web browser" thread from 2000-07-18. :-P On Sat, Oct 1, 2016 at 8:03 AM James A. Robinson wrote: > I was browsing of my old plan 9 mail and this conversation from 2000 made > me think of your thread here: https://goo.gl/PO85oD >
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
I was browsing of my old plan 9 mail and this conversation from 2000 made me think of your thread here: https://goo.gl/PO85oD
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
Wow, That sounds cool. Thanks, Chris > On Sep 22, 2016, at 6:49 PM, michaelian ennis > wrote: > > Not exactly what you meant but Coraid did implement a something like this > that had 9p on it. Sort of. It was an ARM based PCIe card spoke 9p over > something like IL without the IP (bwc called it EL) using network ports on > the card. > > Sometimes they appear on ebay as "coraid mass storage NIC" or some such. Not > the repurposed SuperMicro Cards but something that looks mor complicated with > a SO-DIMM socket on it. > > The ARM CPU was also used for other services running on/for the platform that > were performed by the card. The card could be powered by POE so the chassis > could be powered down and the card could still be accessed. The firmware on > the card was, IIRC, not quite plan9 but constructed mostly from plan9. > > Ian
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
Not exactly what you meant but Coraid did implement a something like this that had 9p on it. Sort of. It was an ARM based PCIe card spoke 9p over something like IL without the IP (bwc called it EL) using network ports on the card. Sometimes they appear on ebay as "coraid mass storage NIC" or some such. Not the repurposed SuperMicro Cards but something that looks mor complicated with a SO-DIMM socket on it. The ARM CPU was also used for other services running on/for the platform that were performed by the card. The card could be powered by POE so the chassis could be powered down and the card could still be accessed. The firmware on the card was, IIRC, not quite plan9 but constructed mostly from plan9. Ian
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Would this be fast enough for what we experienced back then with early > websites, however? What with the stats on how people close or click away from > a tab within N seconds if it hasn't fully loaded yet, I'd think that having > to compile at all could've been prohibitive to people taking this route vs. > web forms. Though, I'm not sure how user behaviors or expectations of speed > were back then for the web. I have a couple of ideas in this area. If a more guided interface is needed then when you mount a service you can hook up a console to a file using "con" command allowing for interactive prompts such as "enter search criteria" and responses. Still no remote code required. Another option is to provide a readme.txt file describing the service, relevant files, etc. Inside that document are examples of shell commands that you can run. echo 'search cat pictures' >> ctl Open the readme in acme, edit the examples, select and middle click on it and it runs the command. You learn how to use the service and again, there is no remote command execution other than what you selected and ran. > > I was thinking what may have eventually happened would have been an > interpreted language would pop up that would be what web applications were > written in, sort of like java applets, except not embedded in the browser, > and hopefully in a simpler language. Early web applications were also very > simple 'put info in textbox and hit enter' forms, if I remember correctly, so > a small, expandable runtime that would be quickly started up in a sandbox > might have been on equal footing with html, assuming it was indeed able to > start up and run quickly (or maybe just fork a running one into a new > namespace?). Ideally, developers could then write their own libraries (in C > or whatever they like) that the web language would hook into that could do > more powerful things - and those libraries might be the time to provide > source and makefiles, or binaries if they wanted to keep things close to the > chest. That's possible that an interpreted language would have taken off. With OS level sandboxing, hopefully people run these within the sandboxes, providing access the minimal set needed for the service. > > Thinking more on the 'writing to a ctl file' idea, which I'm really getting > into, I was thinking users may have ended up making their own graphical > interfaces for web services; UIs that abstracted away the actual writing to > ctl files and put it in a GUI for less advanced users. It'd've been > interesting to see a competition in UI design among OSS interfaces for web > services, sort of like what we see today with apps for reddit on phones > (except hopefully they wouldn't all be awful). Or, maybe everyone would just > use the service-provider's provided interfaces. I think that many GUI's were created to hide ugly, inconsistent and large layers underneath. I have a hypothesis that if you start with a small, well designed system with a simple interface that people can and will use it of the alternative is a system that is brittle, complex and allows accidental security breaches at the click of a button. Textual interfaces can good and usable, with a bit of learning. Add graphics only when the problem warrants it (eg. CAD) or it truly simplifies the interface. > Do you think there would've been fewer large databases if things had gone > this way? Just thinking on my banking example, it seems like it'd be easiest > to just have a /bank.com/users/ folder with the relevant files in > it that users could union-mount, since you're not forced to show things > through a web interface. Though, I suppose a bank could just expose that > folder as an interface for what's actually a DB running in the background. The bank may expose files, but it doesn't necessarily mean you can edit them like simple text files. Plan 9 has some really interesting paradigms with read only files, updating using control file protocols, append only files, file descriptors that return errors for invalid writes. I've only scratched the surface. It could be a really interesting project to write up how different paradigms work for certain scenarios. Chris
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
It's all based on their new language go. On 9/20/16, Marshall Conover wrote: >> Ken and rob are currently working at google trying to > make sure it stays so - the idea being that if the stupid people that > control the real OS can't be made to learn at least they'll make > themselves an abstract environment that can hide the past and all the > pain, to then work on interesting, more challenging ideas on the > higher level (in the web) without distractions. > > So, to make sure I understand correctly, the idea is to leave the actual OS > behind, and have all future development done entirely in the web, with the > browser as an application platform/web services being the OS, and finding a > way to make web services more composable? And this is being actively worked > on by Rob and Ken? I'm tempted to somehow work in the 9front release title > "Why not as a JS library?" > > Is there any more information on this? I'd be interested in seeing what a > design like that would be like, and what challenges they're trying to > address. The browser as a platform and the technologies around it seem like > such a kludge after 20-some years of incremental, meandering progress, I'd > think there might be a lot of difficulty trying to base a simple, solid > system on them. Then again, I'm not a web dev, so I could be > misunderstanding what goes on in that domain entirely. > > Thanks again! > > mars >
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
I was thinking more along the lines of hardware implementation of 9P minus any OS. For example, a disk serves up a filesystem via 9P or an Ethernet device serving a /net with 9P. Chris > On Sep 20, 2016, at 2:16 AM, David Pick wrote: > >> On 19/09/16 21:55, Chris McGee wrote: >> >> >> >> Maybe 9P could be implemented in a SoC. > > It already has: the Raspberry Pi is built round a SoC... > ...all that's needed is to boot from SoC ROM instead of the SD card. > > -- > David Pick > Network Security Manager, IT Services > Queen Mary University of London > Tel: +44 (0) 20 7882 7079 > Mob: +44 (0) 7973 379 161 > E-Mail: d.m.p...@qmul.ac.uk > > Normal working days are Monday to Wednesday inclusive > > Worried about Cyber Security? Check out the > Cyber Security Information and Training described at > http://connect.qmul.ac.uk/qmandyou/staff/items/2016/item177974.html > >
[9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Ken and rob are currently working at google trying to make sure it stays so - the idea being that if the stupid people that control the real OS can't be made to learn at least they'll make themselves an abstract environment that can hide the past and all the pain, to then work on interesting, more challenging ideas on the higher level (in the web) without distractions. So, to make sure I understand correctly, the idea is to leave the actual OS behind, and have all future development done entirely in the web, with the browser as an application platform/web services being the OS, and finding a way to make web services more composable? And this is being actively worked on by Rob and Ken? I'm tempted to somehow work in the 9front release title "Why not as a JS library?" Is there any more information on this? I'd be interested in seeing what a design like that would be like, and what challenges they're trying to address. The browser as a platform and the technologies around it seem like such a kludge after 20-some years of incremental, meandering progress, I'd think there might be a lot of difficulty trying to base a simple, solid system on them. Then again, I'm not a web dev, so I could be misunderstanding what goes on in that domain entirely. Thanks again! mars
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Well, since everyone is trying to make the web the OS - see the chrome > boxes, for example - why not cut out the middleman and just have the OS > doing things? It seems like it's going to happen no matter what. Well, it's happened, so now we have two shitty OS: chrome on top of mac os x. Naturally interoperability between different programs from the web and anything else (even other programs in the web) is non-existent. Ken and rob are currently working at google trying to make sure it stays so - the idea being that if the stupid people that control the real OS can't be made to learn at least they'll make themselves an abstract environment that can hide the past and all the pain, to then work on interesting, more challenging ideas on the higher level (in the web) without distractions. Please correct me if I'm wrong, my googleinos :)
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Also, external storage (hdd, ssd) with a built in filesystem exposed as 9P. > UTF-8 file names, of course. already exists, see coraid.
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
On 19/09/16 21:55, Chris McGee wrote: > > > Maybe 9P could be implemented in a SoC. It already has: the Raspberry Pi is built round a SoC... ...all that's needed is to boot from SoC ROM instead of the SD card. -- David Pick Network Security Manager, IT Services Queen Mary University of London Tel: +44 (0) 20 7882 7079 Mob: +44 (0) 7973 379 161 E-Mail: d.m.p...@qmul.ac.uk Normal working days are Monday to Wednesday inclusive Worried about Cyber Security? Check out the Cyber Security Information and Training described at http://connect.qmul.ac.uk/qmandyou/staff/items/2016/item177974.html
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Mounting a bin directory from some remote servers is a potential vector for malicious code and requires all services to provide binaries for all platforms (arm, x86, riscv,...). Instead, serving the source code and mkfile allows for audit ability (what did I just run?) and support for their own platform. Plan 9 compilers were designed not just to produce optimal code but also for speed of compilation. Would this be fast enough for what we experienced back then with early websites, however? What with the stats on how people close or click away from a tab within N seconds if it hasn't fully loaded yet, I'd think that having to compile at all could've been prohibitive to people taking this route vs. web forms. Though, I'm not sure how user behaviors or expectations of speed were back then for the web. I was thinking what may have eventually happened would have been an interpreted language would pop up that would be what web applications were written in, sort of like java applets, except not embedded in the browser, and hopefully in a simpler language. Early web applications were also very simple 'put info in textbox and hit enter' forms, if I remember correctly, so a small, expandable runtime that would be quickly started up in a sandbox might have been on equal footing with html, assuming it was indeed able to start up and run quickly (or maybe just fork a running one into a new namespace?). Ideally, developers could then write their own libraries (in C or whatever they like) that the web language would hook into that could do more powerful things - and those libraries might be the time to provide source and makefiles, or binaries if they wanted to keep things close to the chest. Thinking more on the 'writing to a ctl file' idea, which I'm really getting into, I was thinking users may have ended up making their own graphical interfaces for web services; UIs that abstracted away the actual writing to ctl files and put it in a GUI for less advanced users. It'd've been interesting to see a competition in UI design among OSS interfaces for web services, sort of like what we see today with apps for reddit on phones (except hopefully they wouldn't all be awful). Or, maybe everyone would just use the service-provider's provided interfaces. Do you think there would've been fewer large databases if things had gone this way? Just thinking on my banking example, it seems like it'd be easiest to just have a /bank.com/users/ folder with the relevant files in it that users could union-mount, since you're not forced to show things through a web interface. Though, I suppose a bank could just expose that folder as an interface for what's actually a DB running in the background. > This was however because I wanted to call a site "Troff the Crime Blog." I chortled. I was wondering if maybe today a similar thing could be done with docker or the rocket containers, but I'm not familiar enough with them; it seems like they're somewhat baked images, not just namespaced folders with the relevant things union-mounted inside them, so it might not be easy or fast to just union mount the things you need for the web-app you're loading in a new docker instance. Also, they have no UI support, thought it seems like you can dynamically link an X socket into them to draw to an X session on the parent machine with some extra work. Let me know if this conversation is not really appropriate for this mailing list at this point, by the way. I don't want to be a nuisance. I appreciate the discussion so far - thanks! mars
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
If plan 9 had taken off I wonder if there would be peripherals with built-in 9P support. For example, a network adapter that you can mount into /net/etherxyz over USB, PCI using a 9P connection. No driver needed, except to communicate with the bus. Also, external storage (hdd, ssd) with a built in filesystem exposed as 9P. UTF-8 file names, of course. Maybe 9P could be implemented in a SoC. Chris
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> > > You just mount search engine, route planning tool, or even shopping site > > and echo commands into the ctl file. > > I hadn't thought of this - was more thinking on the user union mounting, say, > google.com/bin into their bin directory and running a google operation. The > concept of just echoing into a ctl file is really interesting from a security > perspective. Right, in this case there is no remote code execution. Web users run all kinds of code they are unaware of today. It's a major problem. It also helps to create a certain uniformity and expectation of how services should work. Mounting a bin directory from some remote servers is a potential vector for malicious code and requires all services to provide binaries for all platforms (arm, x86, riscv,...). Instead, serving the source code and mkfile allows for audit ability (what did I just run?) and support for their own platform. Plan 9 compilers were designed not just to produce optimal code but also for speed of compilation.
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
On Sat, Sep 17, 2016 at 11:51 AM, Jules Merit < jules.merit.eurocorp...@gmail.com> wrote: > Troff + net, > This spring (in the northern hemisphere) I had toyed with the notion of using troff as an intermediate format for publishing public record data sets. This was however because I wanted to call a site "Troff the Crime Blog." True story. Ian
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
Thanks, Chris! That was a lot more detailed than I had thought into it. > You just mount search engine, route planning tool, or even shopping site and echo commands into the ctl file. I hadn't thought of this - was more thinking on the user union mounting, say, google.com/bin into their bin directory and running a google operation. The concept of just echoing into a ctl file is really interesting from a security perspective. > Multimedia documents with both pictures and text are compiled into self contained files kind of like PDF without hyperlinks and arbitrary code expectation... This rich format is for longer and more focused reading sessions: studying a topic, leisure reading. I had originally been thinking along these lines, but the more I think about it, the more I think there would have been a lot of demand for flashy displays, and so I think something like a library for a flash-like language that users would execute would've popped up. While I think users could've gotten used to normal text (and it actually may have been more intuitive, especially for older, non-technical people who are distracted by flashy things), I think the people paying for development would've wanted more, including graphics and animations. >Also, services are designed to be focused enough and standard enough that they can be easily interact with other services using pipes, redirects, etc. so that the user can combine them to suit their needs. This would've been amazing. > Single signon is achieved using symmetric encryption. If the service recognizes your public key and you are able to sign a message using your private key you can proceed. Not sure how much overlap there is here with what is in tls and factotum. Something like factotum could be useful to allow you to specify different keys (identities) for different services. This would be interesting, as well, when combined with network+union filesystems, for being able to do something like run a website like reddit with pointers to files hosted by users themselves. The possible advantage I was thinking about is that a user could post comments as files stored on their local accounts with group permissions they can specify, allowing them to only have their friends see those files; the 'reddit' site would only host the file pointers, and people would only be able to see those comments on the reddit reader-app if they had the correct permissions. Usrers could then delete their comments at will without worrying about the site holding onto them in old DB backups or the like. Thanks, also, Hiro! > There is nothing wrong with the web having a limited scope of features. Well, since everyone is trying to make the web the OS - see the chrome boxes, for example - why not cut out the middleman and just have the OS doing things? It seems like it's going to happen no matter what. > If they are on par, then why waste time with the web part? Well, that's the point, isn't it? You can access applications from anywhere, and you don't need a browser to act as a platform to do it. You also don't need to install them using some wizard and registry and all the other BS. > security and privacy in the web is hopeless. it plainly was never a real goal. Would plan9 have made it reasonable to become one? > popular things tend to drive people. doesn't say anything about the technical or even educational qualities though. I think this is a good point. I was also thinking that ease-of-entry would likely have developed more on the application side if more people had been using it. > Plan 9 technically is just one small collection of more consistent alternative building blocks, but the web has ignored, reinvented or misunderstood most others, too. Yeah, this is sort of why I've been thinking about this. I've almost begun getting frustrated when I see all the redundant design in the browser that, at least it seems, could've just been done with the OS. Every time a friend or intern pings me with a web problem, it seems more and more like the web is just a series of kludges from trying to make the newspaper man be a song-and-dance man who gives you live television. Thanks for the thoughts! mars
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
Troff + net, I added ideas from vrml's for AR glasses I use for HUD documents as I look off monitor still bashing the keyboard. Web proxy for format translation. On Sep 17, 2016 10:06 AM, "hiro" <23h...@gmail.com> wrote: > It's hard to have a technical argument about this, because technical > consideration was never a big driver of web "technologies". > > > Web programming would have also have started off with far greater ability > There is nothing wrong with the web having a limited scope of features. > > > Web games, video-streaming applications, etc. on par with local > applications > If they are on par, then why waste time with the web part? > > > waiting years for even simple things to be standardized > They never actually did wait. What they implemented instead was always > horrible, and the incompatible standards created after the fact just > make it even worse. > > > cookies and other privacy issues > > sandboxed > security and privacy in the web is hopeless. it plainly was never a real > goal. > > > beneficial to getting them into programming > popular things tend to drive people. doesn't say anything about the > technical or even educational qualities though. > > > [...] friends in web development, they > > have expressed concerns about ease-of-use [...] > In this case they are liars. i know no single web developer who cares > about ease-of-use. > > > system languages did not [...attract] them. > it's not for everyone to design systems. but they still managed (if i > am to believe you against their will) to waste their time doing > redundant system development, reinventing poorly what we already had, > which they couldn't find enough motivation to learn about. > > "the plan 9 way" is often only used in the sense of being consistent. > This, elegance and cleanness is rarely seen in software, hardly > evaluated and only often demanded. But some principles are just > polished unix ideas and many others did exist before. > > Plan 9 technically is just one small collection of more consistent > alternative building blocks, but the web has ignored, reinvented or > misunderstood most others, too. > >
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
It's hard to have a technical argument about this, because technical consideration was never a big driver of web "technologies". > Web programming would have also have started off with far greater ability There is nothing wrong with the web having a limited scope of features. > Web games, video-streaming applications, etc. on par with local applications If they are on par, then why waste time with the web part? > waiting years for even simple things to be standardized They never actually did wait. What they implemented instead was always horrible, and the incompatible standards created after the fact just make it even worse. > cookies and other privacy issues > sandboxed security and privacy in the web is hopeless. it plainly was never a real goal. > beneficial to getting them into programming popular things tend to drive people. doesn't say anything about the technical or even educational qualities though. > [...] friends in web development, they > have expressed concerns about ease-of-use [...] In this case they are liars. i know no single web developer who cares about ease-of-use. > system languages did not [...attract] them. it's not for everyone to design systems. but they still managed (if i am to believe you against their will) to waste their time doing redundant system development, reinventing poorly what we already had, which they couldn't find enough motivation to learn about. "the plan 9 way" is often only used in the sense of being consistent. This, elegance and cleanness is rarely seen in software, hardly evaluated and only often demanded. But some principles are just polished unix ideas and many others did exist before. Plan 9 technically is just one small collection of more consistent alternative building blocks, but the web has ignored, reinvented or misunderstood most others, too.
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
Hi, I have been pondering the same kind of thing myself lately. In an alternate bizarro universe, what would the web look like that is modelled more around plan 9 concepts. Here's my fantastic take on this. First, there is a focus on simplicity of implementation and interface over flashiness of UI. As a result, services are much easier to use directly rather than having to rely on html/js UI's. You just mount search engine, route planning tool, or even shopping site and echo commands into the ctl file. And you get back results as numbered files with simple text output. User doesn't accidentally run malicious software embedded in the service. It's all just 9P. If a service is complex enough, due to complexity of the problem it is trying to solve (not invented complexity). Source code is posted on the service in C source code form. User runs mk, which is super fast because the compilers are optimized for this. They run the program in a rfork+rio sandbox. Users quickly learn how simple this is and do it regularly so that in trusted programs don't have access to what they shouldn't. The process isn't automatic so it doesn't happen without user knowledge. Pop ups and such are not possible. User wraps the connection in tls if they don't want any snooping. Sensitive services such as banking don't allow unencrypted sessions. URL's are just relative paths, navigable using acme and plumber. Absolute links to sites don't exist since the user can map their namespaces any way they choose. Instead, documents may give 9P connection information and locations. Cross site linking becomes very clear. To facilitate ease of navigation and discovery services pop up to curate documents with nice easy relative linking within that service. Multimedia documents with both pictures and text are compiled into self contained files kind of like PDF without hyperlinks and arbitrary code expectation. Links between documents are relative paths as above. Users are accustomed to using simple text or even markup/markdown for most things. This rich format is for longer and more focused reading sessions: studying a topic, leisure reading. Implementers of Internet services have a strong focus on simplicity of implementation and interface, but also in adopting common conventions. For example, a ctl file where you send commands and numbered directories with results of each invocation. Perhaps a new convention could be to include a readme file and maybe man page with details about how to use the service. Also, services are designed to be focused enough and standard enough that they can be easily interact with other services using pipes, redirects, etc. so that the user can combine them to suit their needs. Services take advantage of the simplicity of plan 9 and 9P to easily sandbox, proxy and load balance their services. Also, commodity and mixed architecture systems are easily integrated for free or new services that are built with whatever hardware they can find. Single signon is achieved using symmetric encryption. If the service recognizes your public key and you are able to sign a message using your private key you can proceed. Not sure how much overlap there is here with what is in tls and factotum. Something like factotum could be useful to allow you to specify different keys (identities) for different services. The point here is that authentication is in the user's control and not the service. The user ever only needs to remember one password or store their thumbprint in one place. That's all I have so far. Chris
[9fans] Questions on the browser as a platform if plan 9 had gained marketshare
Hi all, For context, I am a plan 9 novice - I've played around just enough to add jury-rigged background-image support for rio (for better or worse), implore sl - if I remember correctly - to add the ^B option to 9front's rc that brings the cursor to the current input place, and, for what it's worth, create this: http://i.imgur.com/6iiF3zi.png. I've been wondering about how the web - specifically, the browser as a platform for applications - would have been different had plan 9 become a significant influence in operating systems in the early 90s. I've come to the point where I thought a discussion here might be enjoyable and enlightening, hopefully even to the point of dispelling the playful ribbing that this mailing list may or may not be dead. If this conversation has already occurred, my apologies. The improvement I think plan 9 could have brought to the early web is in allowing the browser to have remained, as I understand it to have been, a medium for mark-up text and images, and have the OS act as the platform for web applications. The process I'm thinking of would be, with the example of a banking application: the user opens the bank's web page in a plan 9 browser; the user clicks a 'login' link; that link is sent to the plumber, which detects it as a web application link and directs it to a service which: - sandboxes it, perhaps by using a 'web' user or just modifying the namespace to show the process a limited set of information; - sets the namespace to prefer any libraries that are on the remote bank machine, allowing the application to always run with the environment the application developers intended; - sets the namespace to include any files the application needs from the remote sandbox, e.g. a directory with the user's banking files. As a result of this, it seems that much of the hooplah around flash, webGL, javascript, etc. could have been avoided, and that web applications from yesteryear could still run today (for better or worse), since they could control their environment. Web programming would have also have started off with far greater ability, instead of having being limited by the abilities of its browser platform and waiting years for even simple things to be standardized. Web games, video-streaming applications, etc. on par with local applications could have been launched as soon as the infrastructure could support them, as the providers could just program the application to do whatever the OS allowed. It also seems it would avoid cookies and other privacy issues, since applications would be sandboxed to only know about the things they have available to them. That said, having had discussions with friends in web development, they have expressed concerns about ease-of-use and their initial interest in the field - if I understand correctly, they feel that html's ease of modification and immediate gratification was beneficial to getting them into programming, which - while my understanding of this community is that here it's not a highly valued thing - is, I think an important point to address. They are application developers, and the web had aspects system languages did not which attracted them. Again, if these thoughts are obvious, my apologies, and if it's deeply flawed, my apologies - but I'd be interested in hearing why. Thanks for your time, Mars