Appliance model of computing

This longish article about what is now called cloud computing was before its time in a way, with none of the new terminology. It’s still ahead of the implementation, and I keep thinking I’ll implement some of it.  In short, it describes an internet operating system (i-glue) based on blackbox standards, rich protocols, and replaceable appliances.

The Rationale for Appliances

It is gradually being accepted that the most sensible view of the future of consumer electronics and computing is the “appliance” model, which is simply that computer components should be as simple to use as toasters – plug them in and they work. This article charts the progress needed to make that model a reality.

First we will describe the “toaster test” – a test of simplicity. Then after discussing the communication standards behind the world wide web, we will start to design a rich set of standards to form the next generation of the web. These standards will form an internet operating system.

The Toaster Test

The basic test of whether a system has reached the level of simplicity indicated by the appliance model is the “toaster test.” Is a device as easy to use as a toaster? If yes, then we are successful. If not, then we have failed the toaster test, and we should simplify the system even more.

There are some interesting things about a toaster, from the point of view of the appliance model of computing. We will investigate these points as a way to get at the fundamental principles, then later apply the principles to more complicated devices and systems. First of all, there are two sides to a toaster. There is the device itself, and there is the outlet that you plug it into – or, “the wall”. The toaster demands electricity, and the wall supplies it. So, there is a “demand-side” and a “supply-side” to the appliance. Seems too obvious to even mention, but keep it in mind: this is the basis for the appliance model of computing presented here.

The Wall		The Toaster
	————————-
(supply side)	(standard of communication)	(demand side)

The second interesting point about toasters is that both sides of the connection are a “black box.” A black box in engineering terms is a device or component about which the details are irrelevant to the operation of the system. In the case of the toaster, the “wall” (i.e. the outlet) supplies electricity at 110 volts alternating current (VAC) plus or minus a few volts, at a frequency of 60 Hz – in the US. We as toaster-users don’t need to know or care where that electricity came from – the details are irrelevant to the system. The toaster itself certainly doesn’t care. In fact, the company that sells electricity might actually conceal the details of how it is made. So, since the wall is opaque to users, it is called a “black box.” The same is true of the toaster. We don’t necessarily know or care how it works. The only important thing in the system is that there is a standard of communication between the two black boxes. We must know that the electricity will be 110 V at 60 Hz. That is the only required standard. Knowing that standard, toaster vendors can innovate and build better toasters, and the utility company can innovate and build better electricity generation, all independently of each other with no side effects.

In the toaster example, the system was the electricity grid, and we discovered that the grid does meet the requirements of the appliance model (it passes the toaster test) because the communication of electricity between devices is fully and rigidly standardized, while the internal details of the supply-side and demand-side devices are not standardized at all – they are black boxes.

Web appliances?

We will now move on to a much more complicated system: the world wide web. We will look at this system in terms of the same principles revealed by the toaster, and evaluate whether the web meets the requirements of the appliance model.

First, it is important to note that “the web” is a phenomenon based on the use of HTML-encoded documents transported using the http protocol. Since it is based on a protocol – which is a standard of communication – it is like the toaster system in that respect. Servers are on the supply side and clients (browsers) are on the demand side. Also, we know that there are different web servers and different web clients, and we don’t necessarily know or care how they work internally, so long as they adhere to the exact standard of communication. So servers and clients are “black boxes.” Therefore the design of http is along the lines of the appliance model.

The main problem with the web currently is that http is not the only standard out there. If you were to build a new web client device that you intended to be as easy to use as a toaster, the device would have a large number of settings and options, and you would be constantly having to upgrade it to keep up with the “standards”. The document types supported on the web are not fully standardized; there are a variety of kinds of cabling and local networks; you have to obtain an IP address and know the address of a name server, some web sites require browser plug-ins and JavaScript, and so on. In fact, the “standards” are changing so quickly that writing software for the web is like shooting a moving target – they are not really standards at all.

The world happens to be on a web kick at the moment. The http protocol has been so successful at building the internet, that we are acting as though it is the only protocol, as if all computing can be reduced to http. But the http protocol was only originally designed for remote document retrieval, and it doesn’t easily extend to other purposes. Nevertheless, developers are using it for a lot of other things, because nothing else is standardized. They are using plug-ins and Java and JavaScript code, in order to do things that are not possible with http/HTML as originally designed.

To summarize: we are in a standards crisis. Although the web (based on http and HTML) is itself a standard of communication, the many non-standard and unreliable extensions have introduced a lot of complexities. So the web has not yet reached the stage of simplicity demanded by the appliance model.

---

Identifying a solution

Internet glue (an internet operating system)

The next generation of the web needs to be based on a richer and more coordinated set of standards, including but not limited to http. If these standards are developed carefully enough, then the internet will act like a distributed operating system and the devices plugged into it will act like appliances – as simple to use as toasters. There will be less of a need for “operating systems” as we know them today, since the networking standards will themselves be the operating system!

Yes, we are proposing to design an operating system which is composed exclusively of communication standards. Any device that communicates by those standards will be part of the operating system.

Whenever an engineer receives a “tall order” such as this, the thing to do is not start working on the solution. Instead it is better to work on the approach to the solution. There is a big difference. Mapping out how we will get there allows us to divide the tall order into manageable projects, before we start on the projects. So, we are going to discuss what a valid solution to the problem would look like, in a question and answer format. Then when the parts of the approach are eventually engineered, we will also have a guide to validating their correctness.

Q: What are we trying to create?

A: Here are three ways to describe the thing:

An internet operating system

A set of standards for the next generation of the web

A system to support the appliance model of computing

Our system will also need a name: for now let’s call it iglue – for “internet glue.”

Q: What would an iglue system look like?

A: Just like a kitchen with a toaster, blender, and coffee machine, the office will have various appliances plugged in to the wall. Your coffee machine doesn’t require your toaster to be version 5.2 or later, and likewise the desk won’t make any strange compatibility requirements of your printer or any other device. These appliances will be independent and more durable than today’s electronics: the components will keep being useful until they break, rather than becoming unusable through obsolescence.

A lot more has been written about individual future computing devices than about future operating systems. Here is an annotated list of some of the appliances we will expect to see in the future.

• • Smart cards – credit card size devices with screens and buttons (special purpose)
  • Palmtop, laptop, notebook-style, and other small portable general-purpose devices
  • Reusable books, newspapers, and wallpaper that can display anything
  • Household appliances and security systems with sensors and alarms that are hooked up to the local network
  • Headset/handset and microphone – a single portable audio device that could be used for phone calls, listening to music, or any other audio need
  • Speakers and microphones for use in a room
  • Desks – with large screens (six feet across) and integrated keyboard/voice control
  • Easels for artistic work – with tactile controls and a set of brushes, pencils, and other tools
  • Virtual reality rooms and headsets
  • Processors – the devices that execute application software
  • File servers and database servers

Although each of these devices will be a complete computer itself, they will participate in the network only as specialized devices adhering to the communication standards set up for that device type.

The device we are calling a “processor” is like today’s computers except that it only has general network ports, not ports specifically for a keyboard, display, mouse, printer, etc.

With an iglue network, you could plug in appliances from different vendors at any time, without any compatibility problems.

Q: Why split up the PC into separate devices?

A: We are proposing that the desk should be a different appliance from the processor, and the file server is yet another appliance. We see a smaller role for integrated PCs in the future. Historically, a lot of cost savings were realized when computers became integrated with terminals, creating the PC or workstation – because only one processor was needed to run the software, run the display, talk to the disk drive, and run the I/O ports. So why are we proposing to split up these functions again?

One reason is durability. For example, in the desk device, the circuitry and software needed to control the display would be matched with the display’s size and capabilities, so you would package all the components together. The device would work exactly as designed until it breaks. By contrast, the “integrated” displays we use today divide up some circuitry and embedded software in the monitor, some on the video card, and other software in the form of a video driver. If you want to upgrade your monitor, you may have to upgrade the whole computer, or vice versa. This creates a lot of waste through premature obsolescence.

Many older PCs that are now being decommissioned would be perfectly suitable as desk devices, even if they are not fast enough to run newer software. With the appropriate internet operating systems, all this old equipment could last a lot longer.

Another reason to divide up the PC is that the cost factors have changed since PCs were invented (or at least the understanding of the true cost of computer systems has changed). CPUs that are fast enough for communications and disk access are very cheap, so there is no reason to cut down on the number of CPUs. But installation and maintenance are very expensive, so there is every reason to make sure one device’s failure doesn’t bring down other devices. Appliance-oriented computing would allow end users to swap out damaged devices without having to hire a trained technician for the task.

Q: Do all appliances have to have embedded microcomputers?

A: An appliances on an iglue network must be capable of carrying on at least one two-way conversation at a time with the device it is connected to, which means it must have an embedded microcomputer. Even old electric appliances like toasters and washing machines could benefit from becoming iglue appliances. Computerizing all appliances in this way may seem expensive: Why buy a toaster with a computer in it when all I want is toast? The answer to this is twofold:

• Cheap electrical appliances are actually somewhat dangerous, and should be computerized for safety. Consider the advantages: no electrocutions or fires. You can also check that all household appliances are off before leaving the house (or the house computer can be set to automatically warn you every time you leave).
• Because every appliance will have this ability, the ability will be made into a single chip and cables will be manufactured with this chip glued in. Once the development costs are paid, the manufacturing is not expensive.

Q: How would we get there from here?

A: Obviously, no matter how compelling is the case for the appliance model of computing, businesses are not going to switch over at the first opportunity. If a business is running Windows PCs, it must continue to run its systems, while adding iglue appliances on the same network. Iglue appliances must work with existing systems. Over many years, businesses may gradually convert, and may no longer rely on proprietary network operating systems.

One of the ways this conversion could occur is to (1) install standard iglue processors and file servers on the network, and then (2) install iglue desk software on existing PCs – as a web browser plug-in, perhaps – that allows users to run software on the iglue processors from their PC. Later, as more and more software is written for iglue, you could install iglue desks instead of PCs. These new desks wouldn’t be PCs and could not run their own applications; they could only display windows from applications running on the iglue processors.

Probably the first real-world application for iglue is to run internet applications. Users are already used to downloading browser plug-ins, so they wouldn’t mind downloading another one that would act as a fully functioning desk appliance. Once installed, users could run remote windowing programs such as on-line ordering, news presentation, and network games. The software would run on a central host but the windows would be displayed locally.

Q: How much standardizing is needed?

A: In order to realize the appliance model, the standards will have to cover everything from cabling and plugs to communications protocols and data structures to the topology of device connections. Here is a list of the levels:

• appliance categories – specifications about what general kinds of appliances might exist
• topology – the layout of what gets connected to what
• cabling – specifications for the physical plugs and wires
• device sizing – specifications for the sizes of devices that could be housed in standard-sized cabinets
• networking – specifications for sending data packets over the cables
• data representation – specifications for creating data structures, and reducing structured data into streams of bits
• protocols – specifications of specific syntaxes by which devices communicate

After having specified all these levels of standards sufficiently, we will have developed an internet operating system capable of supporting the appliance model of computing.

Q: Doesn’t standardizing inhibit innovation?

A: No, standardizing removes barriers to innovation! To illustrate: The IBM PC was a machine that was not based on standards. So to compete with it, other vendors had to clone it in its entirety. They could not innovate, and still have to build PCs according to a strict convention; otherwise Windows and all its software would not run on them. But if the machines had been built according to the appliance model (black boxes connected by communication standards), then vendors could have improved on the black boxes considerably.

---

Describing the solution

Now we have gone through a question-and-answer session about what iglue is (or could be). The reader should have an idea of the scope of the job ahead of us. The next sections describe some specific designs, although they are not yet engineered in detail. The text will get increasingly technical and detailed, so please don’t feel any obligation to make it to the end!

Iglue is just a name for “internet glue”. Although the name “iglue” may not stick, we hope some form of internet glue does, and the concepts in this article can inform any attempt at creating that glue, and evolving towards the appliance model of computing.

Domains, supply, and demand

The first specific design we will propose is the branching network topology. But first, a little history reminder. Networking evolved tentatively: Fully independent computers were hooked up so that they could talk while remaining independent. Networking was optional; the network was below (used by) the machines. Computers were installed, then networks were added.

By contrast, iglue networks are there first, and devices are below (used by) the network. Iglue devices don’t necessarily do anything independently of the network. Network segments connect processors and disk drives and desks – components that are useless by themselves. (Iglue will have to be compatible with existing networks too, of course.)

Networks can be mapped conceptually like roots of a tree. End-user appliances like desks, printers, toasters, and headphones are at the bottom of the network map. These appliances are on the “demand side” of the connection. Each appliance has to be connected through wires (or some kind of signal) to a “supply side” device. There are no peer-to-peer network connections.

A single iglue network tree may cover a whole office or house, or may eventually comprise larger areas. The root devices of an iglue network tree may be internet routers, so that the whole iglue network is part of the internet. However, only one IP address is needed for the whole network, not a separate one for each appliance.

A group of interconnected devices at one location having one owner is a iglue domain. At the root of the domain there is a domain controller. A domain controller is an appliance having at least one demand-side port and many supply-side ports. Its function are:

• • to connect levels of the network together
  • to keep track of the appliances that are plugged in
  • to allow appliances to communicate with each other – it can reserve guaranteed bandwidth
  • to act as a firewall and router between a local network and the internet (or a larger branched network)
  • to listen for outside requests on IP ports and direct these to defined server processes, and make sure that server processes keep running

A domain controller could look like an Ethernet hub, but would be smarter. Typically a small entity (home or business) would own one domain controller. They would plug its demand port into a higher level network from which they purchase connectivity, and plug all of their appliances into its supply ports.

A domain controller can also be used to isolate network traffic or use a different type of cabling for a group of devices. For example, a situation where high speed is required between a group of processors and file servers may use a bus-type network to connect those appliances to a domain controller, and plug the domain into a lower-cost longer-distance type of network. (Incidentally, those server appliances could all be housed in a cabinet, which would make it look a lot like a PC! In fact, we expect that the first iglue devices will be derived from PCs. You could take an existing server and add software that would make it appear to the iglue network to be file server plus a processor plus a desk plus a domain controller, all housed in the same cabinet.)

Some domains have security switched on (they define users and locations, allow setting up storage volumes, etc) while others have it switched off (they just direct network traffic). An interesting case of the non-secure, or “dumb” mode is where a telecommunications vendor supplies bandwidth and connectivity (as they do today) and they also supply the domain and file server and processors (at a central location), while the homeowner just has to supply a dumb domain controller acting as an appliance hub and any appliances he wants. This would completely relieve the home user of any setup and maintenance chores.

On/off modes and reliability

The most useful method of maintenance for appliances is to swap a malfunctioning one with a replacement, rather than try to diagnose sub-component failure on site while the network is down. The swapping method keeps the network as a whole functioning and allows a specialized repair shop to diagnose the failure. Therefore, to pass the toaster test, all the appliances have to be “hot swappable” like toasters.

When swapping, the information has to stay there while the hardware gets changed. Even if every component of the network is swapped out, the information and domain structure must survive. The design for hot-swapping is related to the design of how appliances power-on and off. Here is a discussion of these issues for some of the specific appliance types.

• Desks: Desks may have user-settings that could be lost during a conversion to a new desk. The same is true of many other appliances. To alleviate this, appliances store their information in files on a file server, rather than internally in the appliance. The new desk (if it is the same vendor or compatible) will read the preferences file from the file server, and thereby inherit the settings of the old desk. If it isn’t a compatible model, it will have to be reconfigured. Likewise, when a desk is powered off and back on, it will re-read the preferences file. Windows that are still open when the desk is powered off cause the communication link with the window’s owning process to fail, and the program must exit gracefully on this error condition.
• Processors: Processors can have an internal low-power mode but shouldn’t normally need to be switched off. However, if they are de-powered or swapped, they can re-query the domain controller and file servers for all the information they need to know. Processes that were running during a power failure will of course cease, and their communication links will fail. The other sides of the links (desks, file servers, etc) will fail gracefully. To intentionally de-power a processor, it should have a physical button and indicator light: pressing the button causes it to request a graceful ending to all running processes; then when nothing is running, the indicator light signals the user that it’s OK to pull the plug.
• Domain controllers: Like desks, domain controllers store their current configuration in files on a file server, so a loss of power does not result in a loss of information. The domain configuration file structure is standardized (with room for extensions for different controller models), so the domain controller can be replaced with a new one from a different vendor, and it will resume with the same configuration as the old one, including listening to the same IP ports and launching the same server processes.
• File servers: File servers require backups, and we should take this opportunity to end the era of optional backups. Iglue file servers should have integrated backup schemes built into the appliance. A 1-terabit server, for example, would have an integrated tape drive or secondary removable disk drive capable of storing the whole 1-terabit, and would come with enough media to store backups off-site in rotation. It would also come with a replacement appliance that could read the backup volumes. On failure, the appliance would not have to ask any questions, it would simply read from the backup volume. If the appliance (or whole network) was lost, the same information could be available via the backup appliance and backup media (both of which had presumably been stored off site). To decommission a working or partially working file server, the domain owner would simply change the volume name for each data space defined within the domain. All data in data spaces whose volume name was changed would be moved to the new volume.

Energy distribution

Distribution of electricity, gas, and eventually hydrogen, can participate in the same network topology as electronic signals. Network ports can have digital as well as electric and gas outlets. Here is why:

• It is safer: Only energy that is legitimately requested by an operative appliance is delivered, so leaks and shorts are detected. This is a good idea for electricity, and is essential for gaseous energy like hydrogen.
• The ability to buy/sell energy is practically built in since the information about how much is being used at each site is already known; this can provide the incentive to produce energy at home.
• Energy distribution distances will affect prices, to promote greater efficiency. Today, electricity from one utility is the same price no matter how far it is distributed, and no matter from what source, even though these factors actually affect the cost. In the proposed system, each distributor in a chain would mark up the price, and so the distance would be a consumer price factor. This promotes efficient (i.e. minimal) distribution.

Take the example of a clothes dryer as an iglue device. For maximum efficiency and safety, it should use a gas for heating, electricity for mechanical work, and digital communications to signal completion and to request certain gas and electric power levels. It would also use the DC power supplied by the digital cable to power the embedded circuitry and panel lamps, so that a transformer wouldn’t be needed.

Ownership and billing

A vendor-customer relationship is always established between operator-entities who connect their iglue domains. The vendor side connects its demand-side port to the supply-side port of the customer. The vendor maintains the financial accounts for each of its customers, and attempts to collect money on a regular billing cycle, just as is done for all other service businesses (including telecommunications).

The vendor can bill for energy and data transfer. Iglue domain controllers keep track of energy and data transfer separately for each supply and demand side port. In addition to this regular billing information, arbitrary payment conditions may be attached to any demand-side request by the parent controller. For example to request certain products or services (such as a product download, or guaranteed bandwidth over a period of time for a video-phone connection), the two domain controllers may negotiate a price before the service is accepted. This allows a user to send credit with a mail message by instructing each domain controller in the series from the origin to destination to credit the next one’s account with the same amount. Although the sender and ultimate recipient may be strangers, the form of transfer is safe for small amounts because there is a trusted vendor-customer relationship for each pair of connected domain controllers.

On the lowest stratum, individual consumer appliances are connected to the web: desks, switches, toasters, processors, etc. The household controller will save billing information for each appliance as if it was a separate customer. Although it does not make sense for a household to bill their own appliances for the energy and information they receive, the accounting would still be done so that the energy usage per appliance could be known. If, say, a room was rented out, the homeowner could easily bill the renter for all services received in the room, whether they were for heating and lighting, movies, books, mailing, or any other payment made through the web. Also, this feature could be used to find power/information-greedy appliances to cut operating costs.

Cabling

There are several different possibilities for the design of wires and connectors. All applications require digital connections, most require 12 V DC electricity, and some require AC electricity, and gas or hydrogen.

To start with, we recommend these options and combinations:

• • Ethernet – for compatibility with existing equipment
  • branch networking (such as FireWire or USB)
  • branch networking + 120 VAC
  • branch networking + 120 VAC + gas/hydrogen pipe
  • Fiber optic + 12 VDC

FireWire and USB were designed to connect a “computer” to “peripherals” but for iglue (since iglue does not follow that model), it is used to connect appliances to their domain controllers.

Cabinets and standard appliance dimensions

Because many appliances may be small, they require storage cabinets for safety and dust protection. Each plug type has one or more standard cabinet sizes. Manufacturers of small appliances will make the outside dimensions appropriate to fit snugly in the cabinet. Computer components would generally be plugged in, put in a cabinet, and not accessed thereafter. Cabinets could be wall or ceiling mounted.

Users and locations

Each iglue domain can have any number of users. A family could set up their domain with users for each member of the family. Each user has its own data space, as described below. Users may also have sub-users. For example, a company could have a user for each department, and sub-users for jobs within the department. This would be useful if you wanted to store data at the department level, outside of any specific user’s data space.

Each domain also maintains a list of locations, also in outline form. For example, you could set up locations to correspond to buildings or floors, and each could have sub-locations defined for the individual rooms. Locations also have separate data spaces, like users.

Each iglue domain has its own separate lists of users and locations. A person who uses more than one iglue domain could use the same user name on both domains, but there would be two data spaces, and the two users are different.

Each domain has a root user and root location. These have no names. (To log in using the root user, you would just leave the user name entry field blank.) These exist to provide a place for root-level data.

Data representation

We are moving from the hardware side towards the software side of iglue. It is very important to be able to write software once and use it anywhere. In order for this to be possible, there has to be an agreement on a paradigm for user interfaces, directory structures, application features, and the border between an application and the system. Underlying all of these issues is the way data are represented and stored in general.

Over the internet, the most standard data representation is a byte-stream of ASCII text. E-mail (smtp) and the web (http), for example, use conversations of strings of text composed of keywords in English, with a specific two-byte sequence to represent the end of a line of text. Each letter or symbol is represented by an 8-bit number between 32 and 127. These standards are extremely rudimentary (and somewhat wasteful), yet extremely handy and productive. There is nothing so fascinating about this particular scheme; its main virtue is that it is a standard: it allows different operating systems to talk.

More generally, the data standard in use is files, which are variable-sized arrays of bytes. Disk drives, memory, processors, and communications circuits can all use arrays of 8-bit bytes, so you can transfer a file to a different computer, and the other computer will recognize the contents as the exact same array of bytes. Unfortunately, this extremely rudimentary representation burdens each and every application program with the task of reducing its complex data structures used internally into byte streams, then expanding the saved files back into complex structures. Object-oriented databases have stepped in to alleviate this, but they are not transparently available to end-users, so most software still does not use that kind of storage.

Complex structures

Iglue participates in current internet standards, and recognizes streams of bytes as one of the valid data representations. But it also allows you to represent (store and transmit) data in arbitrarily complex structures, such as those stored in object-oriented databases. There is a machine-independent algorithm used to flatten (or serialize) complex objects into transmittable streams and re-construct them at the other end. All iglue appliances recognize strongly typed data. (Of course, a “file of bytes” is a specific case of typed data, and this data type can be serialized as well, but its serialization is not the same array of bytes as in the original file, because the serialization contains type description information.)

Iglue’s data structures are arbitrarily nested, so a single object may contain arrays of other objects, and so on. This requires there to be a naming convention to be able to access the nested objects. Before we get to that, we need to back up a step and talk about naming and data organizing in general.

Domain names instead of volumes

In today’s computers, files are stored on some named medium such as “the sys volume” or “drive D:”. Novice computer users don’t know what the sys volume is, so the practice of organizing files by volume clearly fails the toaster test, and must be eliminated. Of course, data must ultimately be stored on some volume inside some appliance, but the choice of appliance should be a technical detail that is set by the person owning the domain controller, not something that each and every user and application has to haggle over.

Data in iglue networks is owned by the domain controller (though it may be stored on a separate appliance), so to name data, there has to first of all be a way to name domains. Fortunately, someone has already come up with a system for this: the internet domain name, for example: http://www.inkey.com.

A small digression is in order here. The internet domain name does not exactly pass the toaster test, but iglue uses it anyway. It doesn’t pass because embedding periods inside words is not English and the use of long abbreviated phrases to identify people and documents is probably harder to do than use a toaster. But there are two main reasons we have to use this system. One is that the alternatives to identifying domains, such as numbers, are no better. (After all, telephones don’t even pass the toaster test, when you think of it.) The second reason is that iglue is an evolutionary step in the internet, which is an evolutionary beast. While we don’t care much about maintaining Windows or Macintosh conventions in the slightest, we must pay attention to internet conventions, because there is no other way to be part of the internet. (OK, the digression is over.)

Data references

Back to naming data. Every bit (every 1 or 0) in the universe has a unique name. To name a piece of data, iglue uses (1) the internet domain name for your iglue domain, (2) the user or location defined within your domain – defined below, (3) the file name, and (4) an optional formula to apply to the file. We’ll examine each of these parts:

1. The internet domain name. Let’s say you have a home iglue domain, and the demand port on your domain controller is a cable modem port connected to your telecommunications vendor, whose internet domain name is joecomm.net. You have not gotten your own internet domain name, so you have to get a prefix through the vendor. Let’s say that prefix is smith. So your full domain name is smith.joecomm.net. All of your data belong to that name, regardless of what volumes they are stored on. If you had a subdomain in your house, its data might be further prefixed as in: garage.smith.joecomm.net.
2. The user/location. The concept of a user and location was described above. Each user has its own data space. Each location has its own data space, separate from users. To identify a sub-user or sub-location, you would specify the sub-location followed by the parent, as in this user: shipping.accounting. Or this location: north-loading-dock.warehouse.3500-Main.
3. The file name. Each piece of persistent data has a file name that is unique within its user data space or location data space. There aren’t nested directories as in today’s operating systems; instead file names may contain slashes, which can be used to conceptually group related files. For example, the file named preferences/X-Sheet would store preferences for a document editor called X-Sheet. Since this file would be stored in a user’s data space, that user’s preferences would be active no matter what desk the person is using.
4. The formula. Naming a data file without a formula indicates the whole file. Applying a formula delves into the data and indicates some nested record or group of records or fields. The syntax looks like standard programming code. For example: file[15].name[3] would be a reference to the third letter in the name of the fifteenth person listed in file. (This formula would only work if file was defined as an array of objects and the object type contained a member called “name”, which was itself an array.)

So to reference any iglue data object in the universe, you need these four items. Iglue extends URLs (that any web surfer is familiar with) to reference iglue data. For example, here is a fully qualified reference:

iglue://shipping.accounting@BJMart.joecomm.net/shippinglog

In this example,

iglue:// is the protocol (a required part of any URL)

shipping.accounting is the user (where shipping is a sub-user of accounting in this case)

BJMart.joecomm.net/ is the internet domain name identifying the iglue domain

shippinglog is the file name

If you wanted, say, the truck number of the first item in the shipping log, you could code thus in Java:

log = iglueData("iglue://shipping.accounting@BJMart.joecomm.net/shippinglog");

t_num = log[1].TruckNumber;

assuming that log had been defined as the actual type of the data. There is more to come on programming.

Product references

Software products and published information are not stored in a user’s or location’s data space, because these are copies, not originals. Anything that is published (where you have a copy – you are not the author) is called a product. Products can propagate through a network and be cached on multiple volumes, since they are never changed. To reference products, you do not use the data-naming scheme mentioned above, because you don’t care from which domain or user you are getting the data.

Instead you reference the product name, file name (which is unique within the product) and optional formula. The URL doesn’t work for product references because URLs must contain domain names. Here is an example of a product reference in code:

log = iglueProductData("USA/XYZSoft/Shipping Manager 1.2", "sample");

t_num = log[1].TruckNumber;

In this example, there is a product called Shipping Manager (version 1.2) published by a company called XYZSoft. The full product name is made globally unique by using the country, company name, product name and version. The function iglueProductData gets a reference to a data file distributed with a product: in this case, the file called “sample”.

Other things about data representation

1. You may be wondering how the system would know how to resolve a data member name like TruckNumber from a file. It cannot do this in general: in order for the code samples above to work, the code must reference data type definitions that would normally be distributed with the product whose file types the code accesses.

2. Since iglue is strongly typed, there is no absolute need to standardize on character sets, which code to use for a new line, and other such file details. All of these things are defined by whomever defines the file type. We recommend Unicode for most applications requiring natural language strings, but this is not required.

3. All these details on data representation may seem more complex than necessary. But the intent is to make strong standards that stick, so that innovators can get on with the business of building appliances that adhere to the standards. Suppose you wanted to build an appliance that automatically watered plants, and it needed to store persistent data and have a way to enter various settings. Those data should be part of the iglue domain’s data, and you should be able to enter settings through a desk interface. In order for such an appliance to pass the toaster test, there would have to be no configuration: you would have to able to plug in the watering machine, then sit down at your desk and edit its settings. This would have to be true regardless of the kind of desk, processor, or other appliances that may also exist. A rigidly standardized, highly flexible way to store and name data is therefore required to make this scenario possible.

Application-level protocols

An application-level protocol is a known conversation format between two appliances. We don’t care what goes on inside an appliance: that is a black box. The protocols specify exactly how they communicate. For example, a knock-knock joke follows a protocol: “knock-knock” – “who’s there” – “<someone>” – “<someone> who?” – “<someone> <rest of sentence>”. If a conversation follows that exact script with <someone> and <rest of sentence> replaced with other words, then it follows the knock-knock joke protocol, and it is a valid knock-knock joke. The person saying “knock knock” is the client and the other person is the server.

Don’t confuse the distinction between client and server with the distinction between supply and demand network connections. Client and server refer to the two ends of a particular conversation. The client initiates and the server responds by offering a service. The server is always listening for new conversations, and these conversations must be in the protocol defined for the particular class of server. Many appliances are both clients and servers in different contexts. For example, a coffee machine might act as a client when it asks the speakers to sound the coffee-done tone, but it acts as a server when it waits for a command to start brewing.

Iglue allows any of the familiar internet protocols – http, ftp, smtp, and so on. CORBA is used for the new protocols needed for each type of appliance that acts as a server. CORBA, an existing protocol, is used as a general-purpose structure between a client and server software process, to eliminate the need for each software server component to invent its own protocol. Domain controllers listen to CORBA requests and then send a request to run the CORBA server on a processor. CORBA for iglue allows function calls to send and return serializations of arbitrarily complex typed object data. There are no broadcast messages in iglue, as this feature does not scale up indefinitely (ability to upscale is a vital design criterion).

For example, to talk to a file server appliance, a client would initiate a CORBA connection using objects defined for file server manipulation. To ask for a file, make changes, or delete a file, the requesting appliance would instantiate file-reference objects and call remote methods on them (e.g. “myfile.delete”). Here are some of the iglue protocols implemented using CORBA:

• Domain-control protocol is used by all appliances to talk to their local domain controller. The protocol includes support for: registration of a newly plugged-in appliance; announcements of appliance availability; user logons; requests for opening communication channels to other appliances (locally or across the internet); managing and querying users, locations, and products; mapping data spaces to file server storage volumes; mapping appliances to locations; assigning processes to processors; granting privileges to users, and other security-related tasks; and setting up internet socket listeners.
• Desk protocol is based on the model of X-Window, an existing protocol that manages window-based user interfaces. It is used for desks, notebooks, and any other visual user-interface appliances. The desk appliance is a server and can accept requests to display windows from any source (local or across the internet). The protocol includes features for displaying compressed images and 3-D image manipulation, font caching, and an extensible set of graphical control types.
• File server protocol is used by file servers to allow clients to access and modify stored data.
• Processor protocol is used by processor appliances as servers, to allow domain controllers to request them to start a process. The client (domain controller) sends the requesting user, location, security attributes, and data reference to the software to run as part of the request. The domain controller also sets up an interprocess communication channel between the original caller (another process on the same or different processor) and the new process.
• Iglue internet protocol allows an iglue domain controller to transport packets from the local branched network over internet protocol (IP).
• Printer protocol is used by printers to allow clients to send print jobs, and uses many of the same features as the desk protocol. (The use of a standard protocol eliminates the need for software printer drivers having to be installed into another appliance.)

Other protocols not listed here are specialized ones for controlling audio devices and virtual reality devices. The system is extensible so that programming for new device types can be done without drivers.

Software

To pass the toaster test, software must be transparent. Today’s software is burdened by long installation and configuration procedures, and the fact that the developer must know details about the target machine, and that different versions of used components cannot co-exist, and that each application is monolithic and doesn’t work with or talk with other applications, … and, well, many other problems. A more fundamental problem underlying all this is that software, as it exists today, is application-focused, forcing the user to have to concentrate on the program rather than on his documents or data.

Software products

Iglue software is more structured in order to overcome these problems. First of all, it is distributed as products – absolutely unchanging groups of files that are installed and uninstalled as packages. A product may require the use of a number of other products, which may be from other vendors. So, the process of installing a new product may cascade into a series of fetches of the products that it requires, and the products they require, and so on. But one vendor’s software installation cannot affect another vendor’s existing software. Even if you install an “upgrade,” software written to use a prior version of some other product continues to use the prior version. You cannot overwrite; you can only uninstall. Software products are accessed by their universally unique product name, independent of the storage location.

The fact of current PCs is this: Users keep installing software until the machine is obsolete or they erase everything and reinstall the operating system. Removing applications rarely leaves the machine in the same state as before the installation, so files keep building up or being overwritten endlessly. Iglue does not take this approach. Instead, software can be fully uninstalled, and the domain controller could be set up to disable any product that had not been accessed in six months, then remove it three months after that (as an example). In this way, the system can last forever, perhaps outliving all of the individual appliances that compose it.

Software products are cached on one or more file servers in an iglue domain. We say “cached” because these products are copies of an original authored by the vendor. Products contain a list of signatures for commands that they can execute, the executable code and natural language phrase for each of these commands, and type names for the types on which the commands execute. The executable code may be interpreted (such as Java), in which case it must reference the product to act as the interpreter, or if compiled, it may be compiled into many different object files for different chips, all of which are stored in the same product package.

Note well that software products contain a collection of commands, rather than a monolithic application. This is an essential attribute of the move away from program-centric approaches, toward data-centric approaches to software development. The user creates a document of a selected type, then manipulates it through commands. Instead of selling programs, a software vendor will now be selling document types along with the abilities of those types. Other vendors can deliver additional abilities for an existing type. This allows the user to arbitrarily combine those types into complex documents. Because the data storage system is strongly typed and arbitrarily nestable, the performance of complex documents will be equal regardless of the level of nesting.

Commands are identified by unique signatures. Signatures are written somewhat like function prototypes (interfaces) in Pascal or C++. For example, “(Add p{passenger} to f{flight}) success{boolean}” is a signature that could be used in a distributed airline reservation system. (The type names {passenger} and {flight} are short for the fully qualified type names, which would contain the country, vendor, and product names followed by the type name.)

Commands and Scripts

All user interactions are ties to iglue commands. For example, pressing the “A” key inserts the letter A as expected, and this happens because the desk appliance delivers the command “insert A into this” to the process owning the window, where this is a variable to be resolved by context. Commands can be as simple as document editing keystrokes like this, or as complex as instructions to make airline reservations. Commands can be issued in a natural language, as keyboard shortcuts, selected from a menu, or typed in a standard iglue script syntax. The knowledge that allows an iglue system to interpret commands derives from the base of currently installed software products: no intelligence is built into an iglue kernel (which is an important design point because we don’t want to nail down any specific software functions and inhibit future progress). Any command that can be delivered from a desk to a displayed document can also be initiated from a process.

To interpret a command or script, the iglue processor takes into account the command context, favoring the most nested context. The most nested context is the type name of the most nested document to which command is delivered. If there is a command signature matching the delivered command, for that type, then it is executed. If there is none found, the system searches for a matching signature for the type name of the parent data structure, then its parent, and so on. For example, if (insert s{string} into e{editfield}) is an installed command and the user delivers the command “insert ‘A’ into this” in an editfield context, then both arguments to the command can be resolved and the command can be executed.

Scripts are a series of iglue commands. Iglue script is a programming language that allows a programmer to declare iglue data types, create or reference iglue data, and operate any iglue commands on those data.

Programming interfaces

The API (application programming interface) that the processor appliances expose to software is very simple: it does not contain commands for windows or other user interface, or other things that are part of different appliances. The scaled-down API only supports these kinds of requests:

• • create, examine and change structured data records via handles
  • allocate and free chunks of memory
  • open network channels to other appliances (locally or across the internet), and send and receive data
  • search for software commands by signature
  • execute software commands by product (passing arguments and returning a function result)
  • execute compiled program in debug mode
  • enumerate processor activity – for diagnostic and debugging purposes
  • perform thread and process-related functions: fork, kill, etc.; respond to requests to end
  • sleep and set wake-up timers, or wake-up conditions

To execute software commands, such as “Add p{passenger} to f{flight}) success{boolean}”, the program first has to obtain references to iglue data for the passenger and flight objects, then it obtains a reference to the software command itself, then it requests the processor to execute that command using the supplied arguments. The function result is returned.

All of the other functions that exist in other operating systems, such as handling files and user interfaces, are done through CORBA objects communicating with other appliances (such as file servers and desks). These commands are not part of the processor’s API.

Security with location independence

Software will only run on a processor in a domain where it is installed. It should run as close as possible to the data it operates on. Processors optimize this within the constraints of security and bandwidth.

Of particular interest is the ability to run distributed or remote applications, and open remote documents. Let’s examine the on-line retail example. The goal of a retail program is to allow the public to view a catalog, place orders, check order status, etc. It is much easier and more powerful to write a program in a standard programming language for this purpose, than to develop a series of dynamic web pages forming a web application. Unfortunately we are seeing a lot of web applications today because there is no other widespread standard.

With iglue, you can simply write the program to work from your desk (in any language), then set its security flags to allow the program to be run from any desk in the world. There is no difference between “single-user”, “client/server”, “internet”, and “intranet” applications, since they are all based on the appliance model. The database that your program writes to needs to have a security setting to accept requests from that particular program, but it doesn’t need to be publicly accessible otherwise. To access your program, users would execute an iglue script command, passing as an argument a fully qualified file name inside your domain, such as “Open ‘iglue://mystore.com/catalog3’.” This command could be embedded in a document (or e-mail or a web page) so that your customers would not have to type it. The reference to the file catalog3 resolves the type name of that file, then the type is used to resolve the software command to run. To be successful, there must be a software command having the signature “Open c{mycatalogtype}” installed in your domain, where {mycatalogtype} is the type name of the file catalog3.

Tools assumed to exist

One of the advantages of Unix is that a programmer may assume that certain tools exist, such as tools for sending e-mail, task scheduling, and text processing. These tools are separate programs, but they are so essential that they are treated as part of the operating system. By contrast, in the Windows world, a programmer can assume nothing exists unless it is officially part of the API. In Windows, the API keeps growing as new features are needed, and frequent upgrades are needed. Iglue takes a more Unix-like approach, but in a more controlled way. Programmers do not just blindly assume that certain tools exist: they write code that explicitly requires the presence of certain products (listed by vendor, title, and version number). A product requiring other products can be distributed without its dependencies, and the installation process will fetch the dependent products if they are not already installed. This is important because it is inefficient and burdensome to include general services like database servers, e-mail, and scheduling in every single product needing these kinds of features. It is better to have a smaller number of software tools (much of which will be freeware) that are used by multiple applications.

---

Conclusion

If you have made it to the end, you have read about a design for an internet operating system, on all its levels from hardware and wiring to protocols and software. The concepts and a breakdown of kinds of standards were presented, but the engineering is not yet done to make such a system a reality.

The system is intended to fulfill the promise of the appliance model of computing, and it is argued that standardizing any less than the levels presented here would not be sufficient to pass the toaster test. All of these standards put together in a coordinated way are necessary to make computing as easy as using a toaster.

---