Being "In the Web"

While I'm busy with repairs to the GRUMPS, perhaps we should have a high-level discussion about the evolution of software's treatment data over the last 30 years.

Once upon a time, as recently as the dark ages that we call the 1980's, information was commonly recorded onto long lengths of magnetic tape.  To retrieve the pertinent information within your network, a "robot" would have to move throughout the machine, pick a tape, move it to the tape reader, the tape would be wound and your data read.  That is, if you were located within the facility.

Transferring large volumes of data was often prohibitively expensive for most IT groups, so tapes were often mailed (as in physically delivered... by a person) between facilities.  Highways simply had a higher data throughput than most networks.

A computer was envisioned as a one-application-at-a-time interface, so developers were given full discretion to use the system's resources as they saw fit.  By the 90's, most software was inconsistent, and profoundly insular.  There just wasn't enough network bandwidth to consider data available in "the cloud" (at the time, not more than a diffuse altocumulus cloud).

And then the internet happened.  Everyone was in everyone else's data.  Programs were talking to central servers, grabbing information from a variety of places, and putting it together.  A hundred data access standards were created and destroyed.

Right now, the shape of software is changing.  Far more programs are highly networked, and far more programs co-exist on a single system.  And we've gotten to the point where the system is increasingly dependent upon the broadcast and receival of networked information.

XML has been among the most successful ways to define an data type comfortably interoperable between programs.  Web services (SOAP) in particular define standard to allow data to be queryable.  And increasingly, applications are providing developers a way to broadcast their own data.  A crucial component of the Android operating system is the ability of programs to inform the whole system what data and functionality they have available, such that it can be easily invoked by other applications.

In order to achieve this kind of deeply inter-connected software, restrictions are imposed on developers.  Don't present information anyway, present it in a limited way, and declare the type of data you're using upfront or there'll be hell to pay.  Or you at least won't be able to access your desired information.

This exhibits a fascinating paradox in programming: limitations are profoundly helpful.  Limited vocabularies of interaction can enable richer interaction, by ensuring that various software truly speak the same, simple language.  Essentially, they enforce the data-centric nature of these applications; in REST architecture, one is limited to simple reads and modifications of data.  When you define your operation around the data (rather than UI or rules of operation, say), one allows an application to participate in the cloud.  A program isn't limited by the functionality created by the developers, but can become part of a rich ecosystem of interaction.  An alerts module can be invoked by a hundred other modules.  User data can be combined with a hundred other kinds of data, as long as it is made available.

I knew a developer who declared that any operation in a program should be executable by command-line, enforcing a vocabulary of interaction to better define the behavior of the system, and to allow it to better integrate into the ecosystem of the operating system.  The fact is, most modern software can only benefit from putting its public interaction upfront, and that action is most cleanly defined by data.