9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Marshall Conover <marzhall.o@gmail.com>
To: 9fans@9fans.net
Subject: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
Date: Sat, 17 Sep 2016 15:19:51 +0000	[thread overview]
Message-ID: <CAK0pxsGcr15pw4PO2DOQbpw=95UxztgSRU_DZRtgnrNpMe-=cA@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 3418 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3761 bytes --]

             reply	other threads:[~2016-09-17 15:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-17 15:19 Marshall Conover [this message]
2016-09-17 16:23 ` Chris McGee
2016-09-17 17:04 ` hiro
2016-09-17 18:51   ` Jules Merit
2016-09-19 17:11     ` michaelian ennis
2016-10-01 15:03 ` James A. Robinson
2016-10-01 15:05   ` James A. Robinson
2016-09-19 12:44 Marshall Conover
2016-09-19 17:25 ` Chris McGee
2016-09-19 20:55 ` Chris McGee
2016-09-20  6:16   ` David Pick
2016-09-20 17:42     ` Chris McGee
2016-09-22 22:49       ` michaelian ennis
2016-09-22 22:53         ` Chris McGee
2016-09-20  7:47   ` hiro
2016-09-20  8:09 ` hiro
2016-09-19 22:00 Marshall Conover
2016-09-21  3:11 ` Chris McGee
2016-09-20 16:48 Marshall Conover
2016-09-20 19:46 ` hiro
2016-10-01 20:17 Marshall Conover
2016-10-01 20:21 ` Jules Merit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK0pxsGcr15pw4PO2DOQbpw=95UxztgSRU_DZRtgnrNpMe-=cA@mail.gmail.com' \
    --to=marzhall.o@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).