I blagged a copy of Java from Arthur a while before that when I found out he was working at Sun - I'd used HyperNeWS for quite a while and was in awe of his programming skills.

Edit: Are you this DonHopkins?

http://art.net/~hopkins/Don/hyperlook/index.html

That's me. While I was working at Sun in '90-91 on NeWS, we tried very hard to convince management to hire him to work on HyperNeWS for TNT, but Sun wouldn't give us a requisition (because they intended to kill NeWS, not save it). So I quit Sun and moved out to Glasgow to work with him at the Turing Institute on HyperLook, and ported SimCity to HyperLook.

HyperNeWS aka HyperLook was like HyperCard implemented with PostScript programming and graphics, plus networking. In that alternate universe, PostScript would have been the universal bytecode for the web.

https://www.scribd.com/doc/77192884/HyperLook-Product-Info

https://www.scribd.com/doc/77164708/HyperLook-SimCity-Manual

Arthur's programming and entrepreneurial skills are indeed awesome, and I'm glad I quit my day job at Sun and left the country for the opportunity to work with him! He's now an advisor to my current company: http://pantomimecorp.com/the-team

NeWS was pretty cool... I remember coding for it back in 1989-1990... mostly because of display PostScript stuff...

I actually presented a paper at the 2nd International Conference on the Web in Chicago in '94 about "Extending W3 Clients" which including a suggestion for adding a standard bytecode interpreter to web browsers.

I stopped working on that when I found out about Oak/Java in early '95.

The other "universal bytecode" that came out of Sun and actually has seen a lot of use is Mitch Bradley's Open Firmware Forth based boot ROMs, used by Suns' 68k, SPARC and x86 boxes, Apple's PPC Macs, IBM, ARM, OLCP XO-1, and many other systems.

http://en.wikipedia.org/wiki/Open_Firmware

You might get a kick out of Sun's proposal for "NFS 3.0" aka "NeFS". The basic idea was to put a PostScript interpreter in the kernel for extensibly and efficiently executing distributed and even local file system operations. It not only cuts down on network transactions for the same reason NeWS and AJAX does, but even locally you can avoid billions of context switches by executing "find" and tasks like that in the kernel, for example.

The Network Extensible File System Protocol Specification 2/12/90

http://www.donhopkins.com/home/nfs3_0.pdf (pages in reverse order)

Introduction

The Network Extensible File System protocol (NeFS) provides transparent remote access to shared file systems over networks. The NeFS protocol is designed to be machine, operating system, network architecture, and transport protocol independent. This document is the draft specification for the protocol. It will remain in draft form during a period of public review. Italicized comments in the document are intended to present the rationale behind elements of the design and to raise questions where there are doubts. Comments and suggestions on this draft specification are most welcome.

1.1 The Network File System

The Network File System (NFS™) has become a de facto standard distributed file system. Since it was first made generally available in 1985 it has been licensed by more than 120 companies. If the NFS protocol has been so successful why does there need to be NeFS ? Because the NFS protocol has deficiencies and limitations that become more apparent and troublesome as it grows older.

1. Size limitations. The NFS version 2 protocol limits filehandles to 32 bytes, file sizes to the magnitude of a signed 32 bit integer, timestamp accuracy to 1 second. These and other limits need to be extended to cope with current and future demands.

2. Non-idempotent procedures. A significant number of the NFS procedures are not idempotent. In certain circumstances these procedures can fail unexpectedly if retried by the client. It is not always clear how the client should recover from such a failure.

3. Unix bias. The NFS protocol was designed and first implemented in a Unix environment. This bias is reflected in the protocol: there is no support for record-oriented files, file versions or non-Unix file attributes. This bias must be removed if NFS is to be truly machine and operating system independent.

4. No access procedure. Numerous security problems and program anomalies are attributable to the fact that clients have no facility to ask a server whether they have permission to carry out certain operations.

5. No facility to support atomic filesystem operations. For instance the POSIX O_EXCL flag makes a requirement for exclusive file creation. This cannot be guaranteed to work via the NFS protocol without the support of an auxiliary locking service. Similarly there is no way for a client to guarantee that data written to a file is appended to the current end of the file.

6. Performance. The NFS version 2 protocol provides a fixed set of operations between client and server. While a degree of client caching can significantly reduce the amount of client-server interaction, a level of interaction is required just to maintain cache consistency and there yet remain many examples of high client-server interaction that cannot be reduced by caching. The problem becomes more acute when a client’s set of filesystem operations does not map cleanly into the set of NFS procedures.

1.2 The Network Extensible File System

NeFS addresses the problems just described. Although a draft specification for a revised version of the NFS protocol has addressed many of the deficiencies of NFS version 2, it has not made non-Unix implementations easier, not does it provide opportunities for performance improvements. Indeed, the extra complexity introduced by modifications to the NFS protocol makes all implementations more difficult. A revised NFS protocol does not appear to be an attractive alternative to the existing protocol.

Although it has features in common with NFS, NeFS is a radical departure from NFS. The NFS protocol is built according to a Remote Procedure Call model (RPC) where filesystem operations are mapped across the network as remote procedure calls. The NeFS protocol abandons this model in favor of an interpretive model in which the filesystem operations become operators in an interpreted language. Clients send their requests to the server as programs to be interpreted. Execution of the request by the server’s interpreter results in the filesystem operations being invoked and results returned to the client. Using the interpretive model, filesystem operations can be defined more simply. Clients can build arbitrarily complex requests from these simple operations.

That sounds interesting - I'll have a read.