A Huge Chunk of Blue Sky
Friday, January 13, 1995 by Dave Winer.
Dave's Bluff is Called 
It happened! After telegraphing my ideas thru DaveNet in R E S P E C T 1/9/95, finally a credible web browser developer has asked the question I was hoping someone would ask: "Dave, what do you mean by an open web browser?" My bluff got called! Coooooool.
What NetScape 1.0N did right
Since Netscape came first, it was the first web browser to support scripting, let's look at what they did, and what works and what doesn't work.
In my opinion, there are two scriptable features of Netscape that are of interest to script writers. The first feature allows a script to send a URL to Netscape. Then Netscape jumps to that page.
This feature makes some interesting things possible. For example, you could add a button to a card designed with a neat GUI builder that jumps to a specific page. I've tried this with Iowa, it's neat and will probably be useful. It's great for demos! Pop up a card, click on the "Cool Sites" button, and Netscape shows you the Cool Site of the Day page, http://www.infi.net/cool.html. People *love* that little demo!
But there's one major problem with their implementation of this verb, it isn't synchronous. The call returns long before the page is displayed. Typically scripts need things to be synchronous. If Netscape implements the remaining features I'm asking for, this verb will have to be synchronous if things are going to work properly.
The other thing Netscape did right is support the standard "open document" verb. This makes it possible for a script to take the text in a Eudora message and with one keystroke shoot it over to Netscape for display. Some people, notably Chris Tacy, webworks@sirius.com, have been sending email messages in HTML. Now I can read Chris's messages as they were intended to be read with one little keystroke from within Eudora. On the other hand, I'd like to be able to shoot the text directly at Netscape without having to create a text file on the hard disk. But this is a small thing, basically I'm happy with the current implementation.
The remaining verbs handled by Netscape appear to be of fairly low value to script writers, and probably were included as proof of concept, not because any application had a need for them.
Netscape 1.0N has a couple of major problems for scriptwriters. First, it's very particular about how it gets launched. In my scripts I've had to first be sure that the Finder is in front, and then launch the app using the Finder's "open" verb, I can't use the operating system to launch Netscape, or my machine hangs.
It's not rocket science. Almost all System 7-savvy apps (which is almost everything these days) can be launched simply by telling the OS to launch the app. This is what I meant when I said that Netscape 1.0N is a cranky app. The problem almost certainly is with their implementation of the splash window. They assume that when they get launched that they're the frontmost app. This isn't true when a script launches the app. This came up early in the System 7 transition; FileMaker was the prime example of an app that didn't like to get launched from a script. Claris fixed the problem. Netscape should too.
The second problem is that it doesn't return errors to the script. If you tell Netscape to jump to a page, but it can't get it, it puts up a dialog! Even worse, it uses the Notification Manager, so you get two dialogs if Netscape isn't the frontmost app. Instead it should just return the error message string to the app that sent the message.
Writing a worm script
But there's much more I want to do with the web from scripts than just poke URLs at the browser.
I want to write a worm. I can come ridiculously close to doing this with Netscape, but for a missing verb.
What's a worm? It's much less insidious than its name would indicate. Basically, it starts with a specific web page. It analyzes the text to locate all the pages it points to, adds them to a list, and then repeats the process for each of the linked pages. When it hits a page its already seen, it skips it. Let the worm run to completion. Now you've got a potentially *huge* set of web pages. These scripts are used on Unix machines to explore the web, to gain statistics on the size of the web, and to gather interesting places for human beings to look at. I want to do the same thing for Mac users.
What's missing? A verb that returns the HTML text of the current page displayed in the browser window. That's all.
[Note: It *may* be possible to do this with Netscape 1.0N. I can't tell from looking at the app. If it is possible, I hope someone at Netscape will show me how to do it. Their lead Mac developer, Aleksander Totic, atotic@mcom.com, is reading this stuff.]
Evaluate a bit of text in a script
The worm thing is just a warmup. Here's the *real* killer feature, the one that would truly open up the web to the full creativity of script writers.
Add a markup to HTML that would allow a script to evaluate an expression. If a page contained <=user.name>, the browser would display Dave Winer. If it contained <=clock.now ()> the browser would display 1/13/95; 7:06:23 AM.
To implement this feature, add another helper app, the expression evaluator app. When the browser encounters an <=xxx> command, the text is passed to the expression evaluator. The script runs, returns a value, and the value is substituted for the command.
The script can easily access the context from which it was launched by asking the browser for the text of the page that's currently being displayed. That was the feature that the worm script needed.
This may seem like a little feature, but it's not. Control is being passed out of the browser into a script, which in turn can invoke other apps: a database, a mailer program, a page layout program, a card runner (that's my pet project) or any other app anyone can dream up. An open architecture for helper apps! And they can be very big apps that manage lots of content. It's a huge chunk of blue sky.
There is a solution, I think, for the security issue this raises. What if a page contained:
<=file.deleteFolder (file.getSystemDisk ())>
With no security, the user would jump to the page, wait and wait, watch the disk light go on and stay on. After a very long pause, the page would display "true."
We absolutely cannot let this happen.
Support menu sharing
One final feature and we're done. Support the menu sharing protocol. This allows script writers to easily add commands to your menu bar. Eudora supports menu sharing. AnArchie and StuffIt. Quark XPress. It's a basic open-ness feature. Frontier is a menu sharing server. It's an open standard.
Otherwise, that's it! I wouldn't ask you to script the back button and forward button. Scripts almost never have a need to resize an apps window (that's really the user's domain). Keep it simple, let scripts drive the features. No gee-whiz stuff.
And of course once these features are in, we'll hit new walls, and will need new openings from the browser developers. That's how this stuff always works! ;->
Dave Winer
PS: I had dinner last night at Ridgeside Cafe in Portola Valley with Dave Carlick, dsc@sv.poppe.com, an old friend and an exec at the Poppe Tyson ad agency. Dave is one of the leaders among ad agency types at doing business on the worldwide web. Dave can talk HTML! Cool.
PPS: Today is Friday the 13th. Be careful!
PPPS: I think that Adobe Acrobat could be a major player in the web browser business. Still thinking about this.
PPPPS: I like Scott Turner's definition of an agent the best: "An agent is a trusted piece of software that performs a task on your behalf." Bingo.
PPPPPS: As always, if you aren't interested in this stuff, send me email and I'll happily delete your name from the list. And it's OK to forward it or repost it anywhere you like. The list is expanding -- I'm always happy to add new names. Send email to dwiner@well.com.