From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris McGee Content-Type: multipart/alternative; boundary=Apple-Mail-A71FA371-E64A-4806-BA41-485775D95FD9 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Tue, 20 Sep 2016 23:11:30 -0400 References: In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare Topicbox-Message-UUID: a0090754-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail-A71FA371-E64A-4806-BA41-485775D95FD9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > Would this be fast enough for what we experienced back then with early web= sites, 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 t= o compile at all could've been prohibitive to people taking this route vs. w= eb forms. Though, I'm not sure how user behaviors or expectations of speed w= ere back then for the web. I have a couple of ideas in this area. If a more guided interface is needed t= hen 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" an= d responses. Still no remote code required. Another option is to provide a readme.txt file describing the service, relev= ant 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 an= d it runs the command. You learn how to use the service and again, there is n= o remote command execution other than what you selected and ran. >=20 > I was thinking what may have eventually happened would have been an interp= reted 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 hope= fully in a simpler language. Early web applications were also very simple 'p= ut 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 hav= e been on equal footing with html, assuming it was indeed able to start up a= nd run quickly (or maybe just fork a running one into a new namespace?). Ide= ally, 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 thi= ngs - 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 l= evel sandboxing, hopefully people run these within the sandboxes, providing a= ccess the minimal set needed for the service. >=20 > Thinking more on the 'writing to a ctl file' idea, which I'm really gettin= g into, I was thinking users may have ended up making their own graphical in= terfaces for web services; UIs that abstracted away the actual writing to ct= l files and put it in a GUI for less advanced users. It'd've been interestin= g to see a competition in UI design among OSS interfaces for web services, s= ort of like what we see today with apps for reddit on phones (except hopeful= ly they wouldn't all be awful). Or, maybe everyone would just use the servic= e-provider's provided interfaces. I think that many GUI's were created to hide ugly, inconsistent and large la= yers underneath. I have a hypothesis that if you start with a small, well de= signed 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 secu= rity breaches at the click of a button. Textual interfaces can good and usab= le, 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 t= his way? Just thinking on my banking example, it seems like it'd be easiest t= o just have a /bank.com/users/ folder with the relevant files in i= t that users could union-mount, since you're not forced to show things throu= gh a web interface. Though, I suppose a bank could just expose that folder a= s 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 r= ead only files, updating using control file protocols, append only files, fi= le descriptors that return errors for invalid writes. I've only scratched th= e surface. It could be a really interesting project to write up how differen= t paradigms work for certain scenarios. Chris= --Apple-Mail-A71FA371-E64A-4806-BA41-485775D95FD9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Would this=20 be fast enough for what we experienced back then with early websites,=20 however? What with the stats on how people close or click away from a=20 tab within N seconds if it hasn't fully loaded yet, I'd think that=20 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=20 expectations of speed were back then for the web.

I have a cou= ple of ideas in this area. If a more guided interface is needed then when yo= u mount a service you can hook up a console to a file using "con" command al= lowing for interactive prompts such as "enter search criteria" and responses= . Still no remote code required.

Another option is t= o provide a readme.txt file describing the service, relevant files, etc. Ins= ide 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 i= t 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.
<= br>
=

I was=20 thinking what may have eventually happened would have been an=20 interpreted language would pop up that would be what web applications=20 were written in, sort of like java applets, except not embedded in the=20 browser, and hopefully in a simpler language. Early web applications=20 were also very simple 'put info in textbox and hit enter' forms, if I=20 remember correctly, so a small, expandable runtime that would be quickly started up in a sandbox might have been on equal footing with html,=20 assuming it was indeed able to start up and run quickly (or maybe just=20 fork a running one into a new namespace?). Ideally, developers could=20 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=20 binaries if they wanted to keep things close to the chest.

That's po= ssible that an interpreted language would have taken off. With OS level sand= boxing, hopefully people run these within the sandboxes, providing access th= e minimal set needed for the service.


Thinking more on the 'writing to a ctl file' idea, which I'm really getting into, I w= as thinking users may have ended up making their own graphical interfaces=20 for web services; UIs that abstracted away the actual writing to ctl=20 files and put it in a GUI for less advanced users. It'd've been=20 interesting to see a competition in UI design among OSS interfaces for=20 web services, sort of like what we see today with apps for reddit on=20 phones (except hopefully they wouldn't all be awful). Or, maybe everyone would just use the service-provider's provided interfaces.
<= /div>

I think that many GU= I's were created to hide ugly, inconsistent and large layers underneath. I h= ave 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 sy= stem 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 le= arning. 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=20 this way? Just thinking on my banking example, it seems like it'd be=20 easiest to just have a /bank.com/users/<username> folder with the relevant files in it that users could union-mount,=20 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 m= ean you can edit them like simple text files. Plan 9 has some really interes= ting paradigms with read only files, updating using control file protocols, a= ppend only files, file descriptors that return errors for invalid writes. I'= ve only scratched the surface. It could be a really interesting project to w= rite up how different paradigms work for certain scenarios.

Chris
= --Apple-Mail-A71FA371-E64A-4806-BA41-485775D95FD9--