Their premise is that the computing fabric architecture has the following attributes (the following list is a direct quote from the Von Schwebers):

• The fundamental constituents of a fabric are nodes and links.

• A node consists of processor(s), memory, and/or peripherals -- or their functional equivalents.

• Links provide a functional connection between nodes and serve as the basis of coupling.

• A fabric contains one or more regions of tightly coupled nodes, called cells. The simplest cell is a single node. Tightly coupled means a cell appears the same as a single node, even though it consists of potentially many nodes. Tight coupling may be achieved in hardware, software, or both, though performance will vary greatly with implementation.

• Within the fabric, cells are loosely coupled with each other. A loose coupling of cells does not appear the same as a single node.

• The fabric as a whole, and each cell within, can grow or shrink in a modular fashion, meaning nodes and links can be added and removed.

• The boundaries of the fabric, and of cells within the fabric, are potentially fluid. Nodes from the fabric surrounding a cell may join that cell. Nodes within a cell may leave that cell and join the surrounding fabric. Cells can fission as well as fuse.

What do we gain?
So what do we gain out of computing fabrics? Well, there's an unwritten law that the more memory and the more computing power you can apply to a problem, the better the chance of solving it. Of course, there's also the corollary that all computing problems expand to fit available memory, but we'll ignore that theory for the purpose of this discussion. So, using the fabrics model, massive concurrent processing combined with a huge, tightly-coupled address space will, theoretically, make it possible to solve huge computing problems. For example, the Von Schweber's talk of applications such as massive data warehouses and advanced, distributed supply-chain management systems.

But there are challenges to this architectural approach as well. For example, programming for these things may well be a bear. Historically, multi-processor systems have always had a non-linearly degrading performance curve. In other words, if one processor performed at the obvious 100% of single-processor performance, adding a second processor might move the performance to 160% of single-processor performance, and a third might move it only up to 200% of single processor performance.

In part, this is due to the overhead of coordinating all the actions between the processors and in part due to the fact that not all aspects of program execution lend themselves to parallelization. In fact, like in project management where tasks are on a critical path, meaning one task is dependent on a previous task, many programming tasks must be solved linearly throughout much of the algorithm.