Dave Winer Shares Light Weight Protocols

---

---

 

Links

(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.

Overviews

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

Community

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

General

• 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

Security

• 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.

getNode(node)

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.

checkNode(node)

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).

Notes:

• 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.

Issues

• (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)

 

---

---

More Background On LWProtocols.org

 

In the late 1990s, when the internet was still largely a patchwork of experimental technologies and competing standards, Dave Winer launched a modest but influential website: LWProtocols.org, short for Lightweight Protocols. This website became a hub for developers who sought simpler, more accessible alternatives to the heavyweight distributed computing systems of the time — notably CORBA, DCOM, and RMI.
Winer’s idea was both technical and philosophical: empower independent developers to connect applications across the internet using simple, text-based protocols rather than cumbersome enterprise frameworks.

Today, the modern relaunch of LWProtocols.org aims to recreate the spirit of the original, showcasing its archives and contextualizing its historical role in shaping what became XML-RPC, SOAP, and, indirectly, web services and REST APIs — technologies that define today’s internet.

Origins: Dave Winer and the Lightweight Protocols Movement

A Pioneer in Web Simplicity

Dave Winer, often described as a “web philosopher,” was among the earliest advocates of open and simple communication standards on the web. Before most developers even used the word “blog,” he had already created Scripting News, arguably the world’s first continually updated weblog.
Winer’s resume reads like a timeline of web evolution:

• Creator of Frontier, one of the earliest content management systems.

• Co-author of RSS (Really Simple Syndication), which revolutionized how people consumed news and podcasts.

• Co-developer of XML-RPC, a protocol that later inspired SOAP and web APIs used across the internet.

In the context of the late 1990s, the Lightweight Protocols site was a developer’s laboratory — a place to document ideas about how computers could communicate across the web using XML, HTTP, and simplicity as guiding principles.

Purpose and Structure of LWProtocols.org

The original LWProtocols.org positioned itself as a clearinghouse for information about distributed computing architectures that were “more structured than telnet command protocols or CGIs, but less complex or heavy than CORBA or DCOM.”
Winer coined the term “lightweight” to capture both ease of adoption and low barrier to entry for developers. The site categorized dozens of early technologies that embodied this ethos — protocols that favored human readability, accessibility, and interoperability over complexity.

Featured Topics and Sections

The archival site included:

• Telnet-Friendly Protocols: HTTP, FTP, SMTP, NNTP, and POP — the foundational text-based systems of the web.

• XML Protocols: Explorations into early messaging systems such as XML-RPC, SOAP, and Sun’s XML Messaging examples.

• Distributed Architectures: Descriptions of frameworks like DWhite (Distributed Whiteboard API) and Scarab, which used XML and HTTP to synchronize data across systems.

• Security Discussions: Lively debates about the role of firewalls, tunneling, and email viruses in an increasingly networked world.

These sections were complemented by community-driven lists, developer discussions, and “focused debates” that prefigured the kind of forums and GitHub threads that would later dominate open-source collaboration.

Lightweight Protocols in Context

The Late 1990s Web Environment

In 1999–2000, the web was in a transitional phase:

• The dot-com boom was in full swing.

• Developers were struggling to connect applications over the internet.

• Complex frameworks like CORBA (Common Object Request Broker Architecture) dominated enterprise computing but were inaccessible to independent coders.

Winer’s site emerged as a manifesto for a simpler way forward — one that treated the web itself as the platform.
The vision was prophetic: using lightweight, human-readable protocols over HTTP to connect applications without requiring proprietary software or massive middleware systems.

Early Discussions on XML-RPC and SOAP

LWProtocols.org featured and promoted XML-RPC (XML Remote Procedure Call), which Winer co-created with Microsoft engineers. XML-RPC represented a paradigm shift — a minimalist way to execute procedures on a remote server using standard HTTP and XML.

This idea evolved into SOAP (Simple Object Access Protocol), an industry standard adopted by Microsoft, IBM, and others. SOAP, in turn, became the foundation for enterprise web services — though ironically, it later grew into a “heavyweight” standard itself, something Winer often criticized as straying from the simplicity he envisioned.

Technical Examples: The DWhite API and Firewall Debates

DWhite: Distributed Whiteboard API

One of the most detailed examples on the site was the DWhite (Distributed Whiteboard) API, drafted in March 2000. Despite the whimsical name, it represented an early attempt at real-time collaborative data synchronization — the kind of function now handled by Google Docs or Figma.

DWhite used a Model-View-Controller architecture to synchronize tree-structured data between a client and server. Each node contained identifiers and signatures to track updates, allowing efficient synchronization even across slow connections.
It was a conceptual breakthrough, showing how lightweight XML-based protocols could handle stateful distributed collaboration — a forerunner of the real-time sync frameworks used today.

Firewall Issues Discussion

Another noteworthy section was the Firewall Issues page — an “experiment in focused discussion.” Winer curated a structured debate among developers about whether tunneling protocols through firewalls violated network policies or represented necessary innovation.

The participants — including Ken MacLeod, Jakob Nielsen, and others — debated themes still relevant today:

• The limits of perimeter-based security.

• The tension between accessibility and control.

• The need for user education as a key component of cybersecurity.

Winer’s wry commentary (e.g., “Firewalls are Dilbert’s answer to the Pointy-Haired Boss”) captured his skepticism of bureaucratic thinking and underscored his advocacy for practical, developer-driven solutions.

Community and Cultural Impact

Scripting News and the Developer Community

LWProtocols.org was closely linked with Scripting News, Winer’s daily weblog that functioned as both personal diary and public forum. Many of the lightweight protocol discussions began as posts there, then migrated to the dedicated LWProtocols domain.

Scripting News also hosted classified ads for web developers — an early example of using the web as a professional community tool. The ads section offered spaces for contractors, job seekers, and investors, reflecting the collaborative culture of the emerging web developer scene.

The Ethos of Accessibility

More than just a technical repository, LWProtocols.org embodied a philosophy of openness and accessibility. Winer rejected the notion that only large corporations should define how computers talk to each other.
His “lightweight” approach empowered independent programmers to build distributed systems on their own terms — an ethos that deeply influenced the later open-source movement and API economy.

The Modern Revival

The current version of LWProtocols.org honors this legacy by reconstructing and preserving archived materials from the original site. It serves as both a historical document and a tribute to early internet innovation.
Its modern curator, a software developer with an interest in secure, bespoke systems, revived the site to reconnect contemporary developers with the foundational ideas that made the web open and adaptable.

The updated site contextualizes Winer’s contributions alongside broader discussions of:

• Distributed architectures and cloud computing.

• The shift from SOAP to RESTful APIs and GraphQL.

• The continued importance of lightweight solutions in data security and scalability.

The revived LWProtocols.org thus bridges two eras — the late-90s open-web experiment and the modern, API-driven digital ecosystem.

Dave Winer’s Broader Influence

Beyond LWProtocols.org, Winer’s imprint on the web is enormous:

• RSS (1999): His work on syndication made the modern podcast possible.

• OPML: A format for sharing outlines and lists, widely used for feed management.

• Podcasting: His collaboration with Adam Curry in 2004 helped define the podcast medium.

Even his quirks, like a fondness for Batman memorabilia mentioned in his office anecdotes, reveal a playful, human side to the developer who helped make the internet conversational. His ability to merge technical insight with personal storytelling gave his projects a personality often lacking in software communities.

Reception and Legacy

LWProtocols.org was never a commercial venture or a heavily publicized brand. Its influence spread organically through the developer world — through mailing lists, conferences, and the early blogosphere.

It helped shape key industry discussions:

• WWW9 (2000): Panels and developer sessions on “Distributed Computing on the Web” and XML protocols cited Winer’s work.

• XTech Conferences: Participants like Eric Prud’hommeaux continued the conversation on XML messaging and distributed architectures, many of which began in Winer’s online forums.

These ideas formed the conceptual DNA for the Web Services Description Language (WSDL), REST APIs, and even microservices architecture — the modular backbone of today’s internet.

Reviews and Cultural Significance

While the original LWProtocols.org is remembered mainly by veteran developers, its cultural significance lies in how it documented the web’s grassroots technical culture. Unlike the corporate sites of the time, Winer’s platform invited open experimentation and conversation.

Developers today often rediscover these archives through the Wayback Machine, finding them refreshingly human and creative. The discussions feel candid, informal, and community-driven — qualities that foreshadowed the blogosphere, open-source documentation, and even Stack Overflow-style discourse.

Insights for Modern Developers

The re-emergence of LWProtocols.org offers several takeaways for today’s software world:

1. Simplicity Scales: Lightweight, text-based protocols like HTTP and JSON still underpin modern internet systems because they are easy to debug and universally understood.

2. Community-Driven Innovation: Open discussions, mailing lists, and shared code can outperform corporate standards committees.

3. Accessibility Encourages Creativity: Lowering the barrier to entry expands participation and innovation.

4. Security is Cultural: As Winer’s firewall debates showed, security isn’t just technical — it’s about education, policy, and mindset.

By revisiting LWProtocols.org, developers can see how many of today’s “new” ideas have roots in early open-web philosophy.

 

LWProtocols.org stands as both a historical artifact and a timeless manifesto for the open web. Originally launched by Dave Winer in the late 1990s, it captured a pivotal moment when independent developers reshaped how the internet worked — favoring simplicity, openness, and collaboration over complexity and control.

The revived site serves as a digital time capsule, preserving not only early technical experiments but also the human stories behind them — the debates, humor, and creativity that built the culture of web development as we know it.

In an age when APIs and protocols form the backbone of nearly every app and service, LWProtocols.org reminds us that the best technology is often the simplest one — the kind any curious mind can understand and build upon.

 

---

---