Skip navigation links

Package diva.pod

A Pod, in Diva, is an object that contains a "pile of data." This is our term for complex data structures that evolve with time.

See: Description

Package diva.pod Description

A Pod, in Diva, is an object that contains a "pile of data." This is our term for complex data structures that evolve with time. Pods communicate with each other to form even more complex evolving data structures. For the background ideas from which this package sprang, see the "Thanksgiving Whitepaper".

The data in a Pod is typed, in a coarse sense. We refer to the "type" of data as a protocol. We have identified the following protocols, which we believe cover almost all of the kinds of data that you are ever likely to want to generate, store, view, and manipulate:

The data in a Pod can either be generated internally by the Pod, or come from an external source -- for example, a web crawler, a running simulation, or a visual editing program. A Pod that does not receive data, but only generates it, is called a Generator. By themselves, Pods cannot display data in any way, instead relying on Views to display data.

Pods communicate using Transmitters, Channels, and Receivers. The analogy should be obvious -- except that only a single Channel can be connected to any Transmitter or Receiver. For data to be communicated between two Pods, or between a Pod and a View, some external agent needs to set up the appropriate Channels between these objects. The structure of a system containing multiple Pods and Views can be arbitrarily complex. For example, the Smalltalk Model-View-Controller can be implemented by creating a single Pod, and multiple Views with two channels in either direction between the Pos and each View. (Actually, it's more complex than this, because we have to allow for Layout Pods, which are implicit in most descriptions of MVC. In a non-trivial MVC-style editor, the equivalent of a Layout Pod is required anyway, and significantly complicates the design. By making Layout Pods explicit and reusable, we expect a Pod-based editor to actually be simpler than the equivalent MVC one!)

However, much more than MVC is possible with Pods. For one thing, Pods can receive data from other Pods, and transmute it into a different protocol. Viewers (as opposed to editors) are much simpler to construct than using an MVC-based toolkit. By identifying the key protocols needed for data modeling and visualization, we increase possibilities for reuse -- code is written based around a well-defined protocol, rather than an application need and an ill-formed notion of the structure of the data therein.

In other words, we think Pods are the greatest thing since sliced bread.

Skip navigation links

Copyright © 2024 Central Laboratory of the Research Councils. All Rights Reserved.