The point Bret is making is deeper: Skype and Screenhero shouldn't have to be 'applications' that dig into mucky parts of the OS to try to get screen and pointer sharing to work. And even with those applications, other applications get wonky if they are used via screen-sharing.
"Sharing" (of applications, data, peripherals, and capabilities like network storage) to be a first-level primitive provided by the system and all applications ought to be designed to work with it.
Consider this: we're all connected via networks and bluetooth. So why can't I, in a simple way, let your mouse control my cursor? Or send just part of my screen to part of your screen on the OS level? Or have a photo library on my NAS that smartly caches things I look at often on my iPhone, syncing changes back when I edit a photo? Or share a vim session such that my mouse and keyboard follow my vimrc and yours follow yours? Why do these things have to be built in hacky ways, over and over, specific to individual applications rather than built as reusable building-blocks?
We've gone to so much trouble to bolt sharing on to "personal" computers, when that whole idea is flawed. Engelbart's goal was to create a fundamentally networked system where the combined abilities of everyone would exceed the mere sum of their capacity.
If Engelbart's vision were alive, we wouldn't be excited that we have Skype and screenhero. We'd ask, now that we have these things, how can we build software that uses them to get better outcomes? A medical tool the lets two doctors interact over a patient's EMR and rotate CAT scans together in a way that increases the odds that they get the right diagnosis? A pair programming method that finds more bugs, and gets better designs, more than just one person looking over another's shoulder? A spreadsheet that lets two business founders argue about their core assumptions and business model collaboratively?
Read about the early history of computing to see examples of this. One that comes to mind is the timesharing systems in the early MIT AI lab, where there were no security systems. RMS talks about copying bits of code and configuration that he found in his professors' private folders, and the way that people would snoop on each other and build complex systems out of these shared parts.
I've been working on a project [1] which uses a hypermedia directory protocol [2] to orchestrate Web Workers and WebRTC peers, much like Plan9 did with namespaces. It uses HTTP rather than 9P.
The stated goal is to allow Web interactions to be defined by content rather than the page environment. The approach is an SOA which can be configured by manipulating views of the links exported by Web APIs. Workers can then share the page environment through mediated access.
This particular project is at the head of about 2 years of previous work [3] [4] [5]. There have been some failed approaches, and WebRTC was a detour to get launched [6]. I feel confident that GIDE will solve some of the past problems, though I'm waiting to see if it can achieve all of its goals.
My Slate programming language was intended to feature a module linking protocol that would have an ELF-like layer to link against native C code. And then the idea was that the object-slot graph would mirror or integrate with the file system. But the project has languished a bit, and I need to start over (would be glad to partner with somebody to share ideas).
So is it a question of OS integration, then? At some point these technologies get borged by the OS kernel, and we end up with these features operating as first class citizens. It's hard work, so should we surprised that things start as add-on applications first?
Aren't we in the process of achieving a lot of these goals in a pretty clean way? There was a lot of code to write to get to this point.
We are "in the process of achieving" a whole lot of things we had 30 or 40 years ago, but that never made it into the mainstream OS's of today.
E.g. my favorite pet peeve is how many things from AmigaOS "disappeared" when AmigaOS got relegated to a steadily shrinking niche with the death of Commodore. And this is just one of many "forgotten" operating systems with features that have been left behind.
Consider pervasive scripting of applications (yes, I know about Apple Script, but having spent 5 years in an office full of Mac users, I've yet to see anyone use it; on the Amiga AREXX was something almost everyone used in some form or another; and no, shell scripting is not comparable); consider componentized systems where users regularly install new components that enhance "all" their applications (e.g. need support for 7z? on the Amiga you'd install a new XPK library if you want to support a new compression algorithm, and all programs that want to compress data will support it; need support for an archival format? Install the right XAD library; want your paint program to read WebP? Install a suitable DataType library, and any application that knows how to use DataTypes to load images will be able to load it); consider if end users can replace dialog boxes or other GUI components wholesale in almost all their applications - AmigaOS has a few different alternatives: ARP, ASL and ReqTools that provide things like file-requesters. Because of the nature of AmigaOS, there were quickly apps that would act as shims from e.g. ASL to ReqTools, allowing users to pick and choose the file requester they want without relying on application developers choices.
We took giant steps back when Windows snuffed out most of the competition and with it a huge amount of innovative ideas that current mainstream computer users have never even experienced.
Even the stuff that made it into systems like AmigaOS and many others in the 80's to early 90's were mere shades of many of the visions coming out of the 60's and 70's, but the features in OS's like AmigaOS, OS/2, BeOS and many others were there - many of them are not hard work, but a matter of culture and support for the ideas.
Ok so let me get this straight, the application software used components available in the OS for different stuff instead of each application being a walled garden, having its own implementations of everything. So by upgrading/modifying the OS components, you essentially upgrade/modify the applications? Sounds cool. Can applications use each others modules? Maybe not directly, but what if installing an application provides an alternative component to the OS component and other applications can use that? Or is that just the same thing as downloading a new OS component?
All this stuff sounds pretty cool! And can't we make linux like that? (no hope for windows)
It feels similar to Android intent system. If I want to scan a barcode, an app sends a message to the system asking if anyone can do it. The app doesn't have to build that functionality, nor does it have to be provided by Android itself.
Same with sharing other types of data, installing new apps will automatically appear if they provide the functionality that another app asks for.
Actually, Windows and Macintosh already do that, at least for image, audio and video files. You install a codec, and then all properly-written applications can read and write files in that format.
Agree with this so much. We need to take the UNIX idea to its logical end - everything is a file (or a socket, or something exposable) - then for example screensharing is just a case of me "netcat"-ing my mouse to your window manager, and your video output to my screen. I've never played around with it but I believe Plan9 goes some way towards this idea.
"Sharing" (of applications, data, peripherals, and capabilities like network storage) to be a first-level primitive provided by the system and all applications ought to be designed to work with it.
The opencolbalt/croquet stuff sort of takes this approach, though development seems to have stalled there. http://www.opencobalt.org/
people are not ready to be in continuous collaboration mode, i.e. in the mode there they intensively, in real-time, generate worthy ideas and constructively receive(understand), analyze, improve upon and bounce back the ideas generated by the collaborating partner(s). It is very intensive brain activity requiring matching partners and it wears you off pretty quickly. It is like tennis - possible to do for a couple hours few times a week. Or like musical jam sessions - you can do it for prolonged times only when young, and usually with help of some "energizers".
It is one of the reasons why email is such a mainstay of collaboration.
Yes, "not ready" is exactly right. And this is one of Bret's points: Engelbart wasn't actually interested in technology itself. He was interested in sociology: creating groups of people who were ready to do transformative work by collaborating in new ways. Whether or not this model would work is up for debate. But that collaboration, not any particular piece of software, was what Engelbart was after.
Maybe once we've got basic income and everybody can relax a bit more. People can start collaborating on pie-in-the-sky type projects without so much worry about productivity or their next paycheck. Then doing a collaboration for a few hours a week isn't such a big deal.
"Sharing" (of applications, data, peripherals, and capabilities like network storage) to be a first-level primitive provided by the system and all applications ought to be designed to work with it.
Consider this: we're all connected via networks and bluetooth. So why can't I, in a simple way, let your mouse control my cursor? Or send just part of my screen to part of your screen on the OS level? Or have a photo library on my NAS that smartly caches things I look at often on my iPhone, syncing changes back when I edit a photo? Or share a vim session such that my mouse and keyboard follow my vimrc and yours follow yours? Why do these things have to be built in hacky ways, over and over, specific to individual applications rather than built as reusable building-blocks?
We've gone to so much trouble to bolt sharing on to "personal" computers, when that whole idea is flawed. Engelbart's goal was to create a fundamentally networked system where the combined abilities of everyone would exceed the mere sum of their capacity.
If Engelbart's vision were alive, we wouldn't be excited that we have Skype and screenhero. We'd ask, now that we have these things, how can we build software that uses them to get better outcomes? A medical tool the lets two doctors interact over a patient's EMR and rotate CAT scans together in a way that increases the odds that they get the right diagnosis? A pair programming method that finds more bugs, and gets better designs, more than just one person looking over another's shoulder? A spreadsheet that lets two business founders argue about their core assumptions and business model collaboratively?
Read about the early history of computing to see examples of this. One that comes to mind is the timesharing systems in the early MIT AI lab, where there were no security systems. RMS talks about copying bits of code and configuration that he found in his professors' private folders, and the way that people would snoop on each other and build complex systems out of these shared parts.