> 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/<username> 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
