Talk:Don Hopkins

untitled

Cool! Don is an Official Unix Hater. I recently read about Don's OLPC work and I was wondering where I had read that name before...

Client/Server -vs- AJAX

In reference to this revision: https://en.wikipedia.org/w/index.php?title=Don_Hopkins&diff=prev&oldid=742349428 "remove resume-speak; he's just saying he built client-server applications, nothing notable there."

The "resume-speak" removed was: "and built "AJAXian" applications for the NeWS window system 17 years before the term was coined."

I disagree with the justification for removing that text, because AJAX applications are fundamentally different than client/server applications.

It's the essential difference between X11 and NeWS. X11 is a client/server system, but NeWS, like AJAX, has a scripting language (PostScript) on the server side (that is, the NeWS window server, equivalent to the web browser).

The point of NeWS (like AJAX) is that you can program local graphics, interactivity, and application specific protocols in the scripting language, which runs locally in the NeWS server (like a web browser), and optimizes network traffic, which was possible with (and the whole point of) NeWS, but not with X11, for example.

Another good way to explain the similarity between NeWS and AJAX is mentioned on the NeWS page:

   NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
   used PostScript code instead of JavaScript for programming.
   used PostScript graphics instead of DHTML and CSS for rendering.
   used PostScript data instead of XML and JSON for data representation.

Insofar that it's resume-speak, if you look at my resume, you'll see I've done a lot of notable software development with NeWS, including commercial product and free software, pie menus and tabbed frames, user interface toolkits (The NeWS Toolkit, OPEN LOOK), hypermedia browsers and authoring tools (HyperTIES), text editors (Emacs), window managers, runtime editable and scriptable gui builders (HyperNeWS/HyperLook), programming examples like PizzaTool, and games like SimCity, all of which were based on what we now call "AJAXian" architecture, not just "client/server". And I founded, maintained and moderated an international mailing list about NeWS (NeWS-makers@brillig.cs.umd.edu) for several years.

I've published a paper about some of that work in 1989, the lead cover article of the user interface issue of Dr. Dobb's Journal about NeWS pie menus in 1991, and also wrote a chapter in the Unix-Haters book about the X-Windows Disaster in 2003, which explains the difference between client/server systems like X11 and extensible "AJAXian" systems like NeWS. Does publishing a paper, writing a magazine article, and a chapter in a book about extensible NeWS user interface architecture qualify as notable, and does the following sound like an explanation of "AJAX" to you?

Excerpt from The Unix-Haters Handbook: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html

   The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
   The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input eents, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
   As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client an download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
   Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interfae toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun's TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and reating a look-and-feel that is both consistent aross applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations -- and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager.

I developed the first version of pie menus for NeWS 1.0 in May 1987, and released the free source code for NeWS 1.1 on March 30, 1988.

Pie Menus for NeWS 1.1 - March 1988: http://www.donhopkins.com/drupal/node/92

   I release the first version of pie menus for NeWS 1.1 on March 30, 1988. Here is the source code written in NeWS's dialect of PostScript with Owen Densmore's object oriented extensions, using the "Lite" user interface toolkit.

Excerpt from "The Design and Implementation of Pie Menus", Dr. Dobb's Journal, Dec. 1991, explaining how pie menus can transparently replace the default menu class, and custom pie menus may be applied to all window frames, because they run in the window server instead of the clients. The DDJ article would be a good citation to show I was working on "AJAXian" applications 17 years before the term "AJAX" was coined on 18 February 2005 (so that's 17 years and 9 months before).

http://www.donhopkins.com/home/catalog/piemenus/ddj/piemenus.html

   I implemented pie menus in round windwos for the Lite Toolkit in NeWS 1.0 in May 1987. The Lite Toolkit is implemented in NeWS, Sun's object-oriented PostScript dialect. Pie menus are built on top of the abstract menu class, so they have the same application program interface as linear menus. Therefore, pie menus can transparently replace the default menu class, turning every menu in the system into a pie, without having to modify other parts of the system or applications.
   Because of the equivalence in semantics between pie menus and linear menus, pies can replace linear menus in systems in which menu processing can be revectored. Both the Macintosh and Microsoft Windows come to mind as possible candidates for pie menu implementations. Of course, for best results, the application's menus should be arranged with a circular layout in mind.
   My most recent implementation of pie menus runs under the NeWS Toolkit, the most modern object-oriented toolkit for NeWS, shipped with Sun Open Windows, Version 3. The pie menu source code, and several special-purpose classes, as well as sample applications using pie menus are all available for no charge.
   [...] The pie menu shown in Figure 2 is an example of one that I added to the NeWS environment. Clicking on the window frame pops up this menu of window-management commands, designed to take advantage of mark ahead. Because this menu is so commonly used, you can learn to use it quickly, and save a lot of time. At the left of the figure is the top-level menu with commonly used commands and logically related submenus. The "Grab" item has been selected, popping up a graphical submenu of corners and edges. The icon for the bottom edge is highlighted, but has noot yet been selected. Clicking in that slice allows you to grab and stretch the edge of the window frame.

Also here is an article I wrote about the architecture of the HyperTIES hypermedia system we developed at the University of Maryland Human Computer Interaction Lab, which has a diagram (circa 1989) showing the client/server division as well as the objects and procedures running locally in the NeWS server, as well as the HyperTIES client which was itself programmable in FORTH.

http://www.donhopkins.com/drupal/node/101

   Page Formatter:
       The storyboard interpreter drives a page formatter, whose job it is to decide where things go on the page, and to describe the pages by calling remote PostScript procedures in the NeWS server.
       These PostScript procedures describe and manipulate windows and pages.
       A HyperTIES window is comprised of a page for the control panel, a page for the definition window, and zero or more pages for the storyboard contents.
       The formatter describes a page by building a display list of PostScript code associated with the page in the NeWS server. NeWS executes the display list to draw the page's image.
       It puts code to change fonts and show lines of text into the display list. It also creates stamp-pad objects, used to put picture drawing code into the display list, and to render buttons and targets onto the page.
   Objects:
       In addition to the storyboard files (with .st0 suffixes), there exist picture files (with .pn0 suffixes) and targets files (with .pn0 suffixes), describing the objects refered to by the author in the storyboard files.
       You can think of the objects described in the .pn0 and .tn0 files as stamp pads. When an object is refered to in a storyboard, it is used to stamp a picture or a target down at some location on the page.
       The .pn0 and .tn0 files contain an object's class, name, and body.
           Class: An object's class defines its behavior. Currently, the class is the name of a PostScript class defined in the NeWS server. In the future, some classes may be totally or partially implemented in the HyperTIES client, in C or C++.
           Name: In the storyboard files, an author can refer to an object by its name. The master index maps from the object's name to its location in a .pn0 or .tn0 file.
           Body: The interpretation of an object's body, determining its characteristics, is up to its class.
           For all the currently implemented classes, the object's body contains PostScript code to be interpreted by the NeWS server. The server executes the body, which pushes onto the stack the parameters for the /new message, sent to the class implemented in the NeWS server, to instantiate the stamp-pad object the first time it is referenced.

And here's another technical report by Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland, published in 1998 in the ACM Journal of HyperMedia, describing the NeWS version of HyperTIES and its extensible user interface architecture, and the authoring tool based on the NeWS version of UniPress Emacs (which I also helped develop at UniPress), all of which is very "AJAXian" in its architecture. It enabled scriptable local interactivity including pie menus, pop-out graphical buttons, graphical editors for creating said buttons, etc, via PostScript "applets", which pre-date Java applets. (Not coincidentally, James Gosling designed and implemented UniPress Emacs, NeWS and also Java.):

Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser: http://www.donhopkins.com/drupal/node/102 http://drum.lib.umd.edu/handle/1903/362

   Since the HML interpreter functions as the central controller of the Hyperties browser, the functionality of the interface may be changed by redefining control commands passed from the interface to the interpreter. When a button is activated, it generates an HML command string to be interpreted. In one existing database, intended for use in an information kiosk, it was desired to simplify the interface by eliminating the presentation of brief definitions when a link was selected, jumping directly to the intended article. This could be accomplished by simply redefining the command that displays definitions to the one that displays articles (via the macro facility).
   Since storyboards are text files, they can be created and edited in any text editor as well as be manipulated by UNIX facilities (spelling checkers, sort, grep, etc...). On our SUN version Unipress Emacs provides a multiple windows, menus and programming environment to author a database. Graphics tools are launched from Emacs to create or edit the graphic components and target tools are available to mark the shape of each selectable graphic element. The authoring tool checks the links and verifies the syntax of the article markup. It also allows the author to preview the database by easily following links from Emacs buffer to buffer. Author and browser can also be run concurrently for final editing.

Sorry for the wall of text. Could someone please undo that edit, or rewrite it in a better way that doesn't sound so much like "resume-speak" and can't be misunderstood and confused with ordinary non-extensible client/server applications? Thank you!

Xardox (talk) 23:14, 1 March 2017 (UTC)

"Deep Crack"

Here's a citation for the "Deep Crack" reference. I don't know if that's a valid citation for wikipedia, though.

https://donhopkins.com/home/archive/humor/deep-crack.txt

Xardox (talk) 14:41, 10 February 2021 (UTC)