clearspring - the widget network.

Widgets and Placements, and their corresponding ID schemes, are fundamental notions within the platform -- you'll see these mentioned throughout our tools and documentation.

Widgets and Widget IDs (WIDs)

Every single widget registered with the Clearspring platform, including any BLOBs created using Launchpad, is identified by a unique identifier, a WID. The WID is a 64-bit hexadecimal string. You don't need to worry (and shouldn't count on) the exact format, just know that they always exist, are always unique, and do not change for the entire lifetime of the widget.

 

Placements and Placement IDs (PIDs)

To borrow an analogy from object-oriented programming, a widget is a class. It only really exists for the end user once it is instantiated--i.e., once it's added to a web page as an <object>, <embed> or <script> tag. Once the first instance of a widget is created (a so-called "seed"), users can get their own versions and spread them throughout the web. To continue this analogy, we call each concrete instance of a widget a placement, and give it a unique identifier, called a PID, in the same 64-bit format.

Although a widget has only one WID, there can be any number of PIDs associated with it -- one for each placement.

Creating Placements (PIDs)

How are new placements (and their corresponding PIDs) created? The system creates them as widgets are distributed virally by end users. For example, Mary places a Pac-Man game on her MySpace page, and Bob sees her profile and likes the game so much that he posts it to his own Typepad blog. In this case, Bob's placement will have a different PID than Mary's. Further, Bob's placement will be associated with Mary's, as our system will track Mary's PID as a parent of Bob's. Cool, right?

 

Placement Metadata and Inheritance

Placements include metadata. This metadata covers a lot of things, but configuration data is the most interesting. Any parameters associated with a particular PID are inherited by PIDs generated from it, unless explicitly overridden by users or via an API call.

At first glance, this might appear similar to the current low-tech model of configuration propagation: users viewing a page's source and copying a widget's tags in their entirety. But rather than store configuration data permanently in the URL, we store it in our servers and template it on the fly. This not only enables better analytics, but more importantly keeps your URLs from being brittle. Want to rename a parameter? No problem. Want to change its default value? Also not a problem. Configuration data isn't stored in placement URLs--it's stored with placement IDs and templated into your widget as it's served. 

 

This mechanism of configuration distribution is discussed in much greater detail in the Widget Configuration documentation section.