Dave Winer Shares Light Weight Protocols

This website was first created in the late 1990’s by Dave Winer. It was directed at web developers and coders. The domain has obviously been purchased a number of time. It's seen a variety of other uses from a Chinese site to a florist site to a fashion blog. When its domain recently became available I thought it would be great to recreate the essence of the original site using archived content.

A lot has happened to the WWW in the past 15+ years. But we still have web masters, developers, coders working on the web every day. For those geeks and techies, you may find this site a fun look at what was happening way back then.

Dave Winer is known for his contributions to outliner applications, scripting, web services, and content management, as well as blogging tools / blogging and podcasting. More information about Dave Winer can be found on his Wikipedia page: https://en.wikipedia.org/wiki/Dave_Winer


(This section linked to all the back pages on the site, which we are not creating- but it shows the scope and detail that Dave shared with the web developers community. Impressive to say the least.)

Lightweight Protocols -- LWProtocols.org

This site is intended as a clearinghouse for information about distributed computing architectures that are more structured than telnet command protocols or CGIs but less complex or heavy than CORBA or DCOM. The term ``lightweight'' in this context refers to both how easy it is for a user to begin using the architecture as well as how easy it is for web developers to get started in development and quickly produce working code.

Telnet-friendly protocols (HTTP, FTP, SMTP, NNTP, POP) are the original and most widely deployed lightweight protocols. Generally, the protocols described on this site provide additional structure in the protocols that ASCII line-based protocols never standardized.

News and Events

  • "Distributed Computing on the Web" Developer's Day track at WWW9   - "distributed computing technologies as applied to applications running over the World Wide Web. [...] emphasis on [...] using remote method-calls/procedure-calls or messaging."
  • "Distributed Computing Track at WWW9" weblog   - Includes the agenda and a discussion forum. (Dave Winer)
  • XML Protocols Shakedown panel at WWW9   - "The goals of this panel are to review [XML protocols] and identify their common threads [...]"
  • XML Protocol Viewpoints   - A gathering of viewpoints from XTech2000. (Mar. 15, 2000, Eric Prud'hommeaux)
  • WWW9 XML Protocol Agendae   - Quick notes for the agenda discussion on xml-dist-app. (Apr. 18, 2000, Eric Prud'hommeaux)
  • Note: general discussion of XML Protocols and Distributed Computing should be directed to the xml-dist-app mailing list.


Protocol Matrix   - Facet-based comparison of XML protocols. (Mar. 29, 2000, Eric Prud'hommeaux)


Scripting News  - Weblog featuring many links on web protocols.

SOAP - WebServices Resource Center  - News, articles, and links about SOAP.

xml-dist-app  - XML Distributed Applications mailing list. To subscribe, send a message to xml-dist-app-request@w3.org with the subject "subscribe".

Data Transfer Architectures


  • Linda Systems  -
  • RPC and Distributed Object Architectures

``Architectures'' are complete systems for distributed computing and usually include services, protocols, or formats for transport, serialization, making requests, and discovery.

Lightweight, cross-platform, language-neutral architectures

  • Scarab  - Open Source communications framework
  • SOAP  - Simple Object Access Protocol
  • Sun's XML Messaging example  - Sending arbitrary XML messages over HTTP.
  • XML-RPC  - RPC using XML over HTTP
  • XML-RPC Extensions
  • XMLTP  - XML Transfer Protocol

Lightweight, language or platform dependent architectures

  • GNU Distributed Objects  - Distributed Objects for Objective-C, GNUstep implementation
  • Java RMI  - Java Remote Method Invocation
  • OpenStep Distributed Objects  - Apple's Distributed Objects for Objective-C
  • Pyro  - Python Remote Objects
  • RemoteCall  - Call functions/methods on a remote Python process.
  • RPC::PlRPC  - Perl module for building Perl servers and clients
  • RPC::Simple  - Perl module for simple OO async remote procedure calls
  • Tcl-DP  - Distributed Programming extension to Tcl/Tk

Other Architectures

  • CORBA  - on DMOZ, Yahoo
  • HTTP-NG  - Results of the now-defunct HTTP-NG activity. Lots of good info on Internet scale issues in distributed computing.
  • [COM/DCOM, ILU, Sun/DCE RPC, ...]

Serialization Formats

  • SODL  - The Simple Object Definition Language
  • XMOP  - XML Metadata Object Persistence
  • [WDDX, LDO-XML, LDO-Binary, XP, ObjectStore, Coins, BizTalk, ...]

Applications and APIs

These applications either implement or use lightweight protocols or are specially designed to work well with lightweight protocols.

  • The Casbah Project  - Distributed application environment.
  • DWhite  - Distributed Whiteboard API for synchronizing trees or graphs of data.
  • DWChat  - DWhite Chat API


  • The IT Security Checkbook  - A 'self help' guide to computer & network security, primarily for security managers, programmers and system administrators. And good for developers who want to consider their needs. – KM
  • Internet Firewalls: Frequently Asked Questions
  • Why Anti-Virus Software Cannot Stop the Spread of Email Worms  - Though based on a flawed premise, an otherwise good article about policy and education as part of a security solution.
  • Web RPCs Considered Harmful  - Describes major issues with Internet security and open standards when writing apps that expose their APIs over the Internet.


Aside from all this techie stuff, Dave Winer was and still is a blogger. I happened to click on a link from the archived Lightweight Protocols page and ended up on archived pages from his Scriptin News that goes way back. The posts are entertaining so I thought I would add a bit of information about them here, supplementing the tech stuff.

This was on the very first Classified Ads page from Scriptin News in 1996

The first page I checked out has archived captures starting in 1994-2015 with 2785 captures. All the posts were great. Sorry I won’t be sharingl the fascinating reads that occurred between the first and the last posts, but they can be found on https://web.archive.org

Classified Ads

Welcome to the new classified ads server on scripting.com. This new service is designed for people in the web development community, people who want to advertise their services, organizations looking for new contractors and employees, developers offering software for sale, and investors looking to tap into the growth of web content development.

The service is free while it's in a trial period. If it catches on, we may charge a reasonable fee. The source code for this suite will be available when it stabilizes, so other people can set up classified ads services. The suite is entirely configurable. It's not hard coded for any specific set of interests.

Last captured updates of this section included pithy statements from Dave Winer:

Don't slam the door on the way out.
When in doubt, blog.
Greetings, citizen of Planet Earth. We are your overlords. :-)

You can find new blog posts by Dave Winer at: http://scripting.com/



DWhite -- Distributed Whiteboard API

(These are examples of two of Dave’s instructive archived back pages.)

Initial Draft -- March 9, 2000

DWhite (pronounced like the name Dwight) is an API for synchronizing trees or graphs of nodes. Although the name is inspired by distributed whiteboards (a GUI application), DWhite actually supports any type of tree or graph of data.

DWhite adopts a very simple "Model, View, Controller (MVC)" API. The core of DWhite allows a client to synchronize it's local copy of a "Model" (tree or graph) with the server's version of the same tree. "Views" and "Controllers" are applications, logically seperate from the DWhite core, that can query and manipulate the Model. Client copies of the Model can be partially or fully populated. The logical view of DWhite and an application on top of it, showing the major flows of data, looks like this:

[wish somebody'd whip me up a PNG and/or SVG of this ]

The Model of all applications are trees or graphs of nodes. Nodes may be major nodes or minor nodes. Major nodes are the primary nodes of information in DWhite and may contain many properties, minor subnodes, and major subnodes. Major nodes may be copied fully or partially. Minor nodes may contain many properties, minor subnodes, and major subnodes, but are always copied in full as part of their containing major node. Every major node in DWhite has at least the following properties:

DW:Id The DWhite ID of this node.
DW:Signature The DWhite signature of this node.
DW:Partial If present, indicates that this is a partial copy

A DW:Id uniquely identifies a node within one tree of an application and never changes and is never reused as long as the tree exists. A DW:Id will always refer to the same node regardless of where it is moved in the tree. A DW:Signature (based on XSignature) records the state of a node at one point in time and is used to check whether or not a node has been updated. DW:Partial indicates whether the node is fully populated (DW:Partial is false or undefined) or partially populated (DW:Partial is true). A partially populated major node always contains a DW:Id, a DW:Signature, and DW:Partial indicator, and MAY contain additional properties as defined by an application.

Minor nodes do not have DW:Id's, DW:Signatures's or DW:Partial indicators, and are always fully populated.

The core DWhite API has only two methods, getNode() and checkNode(). An empty string ("") as a DW:Id always represents the root node of a tree, it is used as a starting point for building the client copy of the tree. The returned root node may have a DW:Id that contains a real (not "") identifier. Application View APIs will also have methods that will return specific (usually partial) nodes within the tree.


Returns a fully populated copy of the node represented by the (usually partial) node. All properties and minor subnodes will be returned. Major subnodes will be returned partially populated.


Takes a partial node and compares its DW:Signature to the server's version of DW:Signature. If they match, then a partial copy of the node is returned (DW:Partial is true). If they do not match, then a full copy of the node is returned, as if getNode() had been called (DW:Partial is false or undefined).


  • future versions will have methods for setting live queries.
  • Need to reference prior art -- possible comparison to WebDAV. There's no doubt that this has been done before, just who?
  • Authentication is expected in the transport/session layer.
  • Distributed relaying of partial and/or full messages.


Firewall Issues

An experiment in focused discussion


This page summarizes points and counterpoints from a firewall discussion being held on the Scripting News Discussion Group.

To best address specific issues on this page, please respond to the indicated message and include the issue number. Issue numbers will not change as they are moved around. Edits and paraphrases not actually written by the indicated author are in [italics]. To suggest a change in wording, followup the indicated posting in the DG.

This page is but a crude prototype for a possible web application for focused discussions.


  • (1) [People interested in security say that tunneling] circumvent[s] the intentions of the firewall administrators. I don't think this is true. (Dave Winer)
    • (29) The intent of firewall administrators is to understand all the communication going across the firewall and assess its possible security impact on the organization. (Ken MacLeod)
      • (30) incoming connections are far more difficult to assess than outgoing connections. (Ken MacLeod)
        • (31) incoming connections are disfuntional when used with a NAT, which is what many home networks use as firewalls. (David Valentine)
    • (32) running other stuff over port 80 to get around firewalls only means better firewalls need to be built. (David Valentine)
      • (33) Unless you do stateful packet inspection, you can't tell if something running over port 80 is a web page, a movie, or an xml-rpc session. (David Valentine)
    • (34) there are two general policies that [security] admins follow: Block everything until assessed [, and] Allow everything until incidents occur (Ken MacLeod)
      • (35) many sites that follow the "block everything" policy inexplicably change their stance to "allow everything" when it comes to SMTP or HTTP, they basically allow anything through. (Ken MacLeod)
  • (2) Did firewalls prevent yesterday's calamatous virus? No way. (Dave Winer)
    • (4) User education is the only thing that can [prevent incidents] (Dave Winer)
      • (12) Several firewall implementations that will only allow certain enclosures in MIME content (both SMTP and HTTP). . (Ken MacLeod)
      • (24) We [...] scan email coming into our exchange server, and we haven't seen any of the nasty email-attachment viruses. •            (Aaron Mathews)
      • (7) The vbs viruses are a social issue for which there should have been a technological fix by now (a software sandbox). •            (David Valentine)
  • (3) Are there really any firewalls? (Dave Winer)
    • (9) People want to believe in firewalls, but there is no such thing. [restate of (3)?] (Dave Winer)
      • (10) firewalls were never capable of performing their function[?] . (Ken MacLeod)
      • (11) firewalls have been subverted by systemic and broad misuse of their function[?] . (Ken MacLeod)
    • (14) Firewalls are Dilbert's answer to the Pointy-Haired Boss when asked if they're doing anything about security. "Oh we have a firewall!" says the PHB. "That means we're safe." (Dave Winer)
      • (15) I don't think it's relevant that there are PHBs at most organizations [...] It's far more relevant that people with interest in security [...] can't put effective security measures in place because so many vendors and application developers continue to work against them at every turn. . (Ken MacLeod)
      • (17) IT managers are sitting ducks when the shit hits the fan. People will get fired. (Jacob Levy)
        • (18) IT Managers should stick by thier [sic] guns(David Valentine)
          • (19) We stuck to our guns when spec'ing network firewall software [... result:] no viruses. (Aaron Mathews)
  • (5) the Web is a relatively safe environment. Email is wide open. No firewalls there. (Dave Winer)
    • (22) even the Web isn't safe as long as you can download apps and run them. Do firewalls stop that from happening (Dave Winer)
  • (6) People who use firewalls do not understand the issues. (David Valentine)
  • (8)[users] were worried that signed code could do anything, and not that unsigned code could be run on the default configuration of the OS. (David Valentine)
  • (13) site security is a combination of perimeter, network, external connections, host, application, and user education issues. . (Ken MacLeod)
    • (23) firewalls are only a perimeter tool . (Ken MacLeod)
  • (20) The firewalls that I think Dave is talking about aren't designed to keep stuff like this out.. some people act like a perimeter firewall will solve all their problems. (Aaron Mathews)
  • (25) firewalls are the wrong approach to security (Jakob Nielsen)
    • (26) they assume that everybody inside the firewall is loyal (Jakob Nielsen)
    • (27) they assume that everybody outside the firewall is hostile (Jakob Nielsen) (28) they do protect against your average script kiddie who is running scripts to probe your ports (William Crim)
    • (36) Firewalls are just a tool in a broader security plan. Receptionists and security guards are in a similar position and face similar issues. . (Ken MacLeod)
  • (37) File types that might be OK as email enclosures: HTML, GIF, JPEG, ZIP, WAV ((Dave Winer)
    • (38) that's the important part of it [...] an analysis must be made. [...] The security analysts' job is [to analyze] the way [a protocol or file format is] used and the applications that use it.  (Ken MacLeod)