Re: New issue: error recovery practices (Re: Proposed TAG Finding: Internet Media Type registration, consistency of use)

At 11:59 PM 2002-05-29, Keith Moore wrote:

>> I would be stunned if a client whose site looked horrible in their
>> preferred browser would be content with "but the W3C validator says it's
>> perfect". 
>
>almost nobody cares what the validator says, because the validator isn't 
>that good a predictor of how things will look to the customer.
>
>but if browsers told content-providers things like "I don't understand 
>this page, it probably looks horrible to your customers" then it would 
>tighten the feedback loop.

We need to hold onto this image: measuring the tightness of the feedback loop: that there is a flexibility, together with a resistence to flexing, characterized by a stiffness property observed in the closed-loop operation.

This is definitely one of the images that one can carry over to large systems (the Web) from servo theory: that the continuation of composability is limited on the one hand by the stiffness of the closed-loop control of the technical contracts at each handshake.  You cannot couple [human interaction] processes through a chain that is all give and no stiffness at all.  

On the other hand, the orthodoxy has to be a stiff resiliency, and not a brittle crystalline demand for perfection, however, because the continuation of composability is likewise limited by the likelihood of failure on fault if there is no resilency through some capability for fault tolerance.

The highest principle that I have found out of this thread, in backing out a high altitude perspective so far, is that of transparency.  The web seeks to be a broker in human intercourse, and in this regard it must be careful that the role it carves out for itself appeals to the parties to transactions as an _honest broker_.

First off we need to baby step the original idea: don't bash MIME-types quietly for fault tolerance.  There are two things going on here.  First we need to say that resiliency, that fault tolerance, is good.  However, quiet repair by the purported user's agent is not good because it lacks the necessary transparency.

Transparency, here, is as used in evaluating financial infrastructure.  The language of business may contain all the concepts we need to fill the void in our ability to articulate this issue.  We start with the image of The Web as a broker, a middleman, and transparency is the ability of the Web to provide a full and faithful representation of each party to the other parties to a transaction.  Without taint of subverting the interests of the parties served to pursue interests of its own.  Call this an honest broker.

The simplest way to derive 'don't recovery quitely' from the business notion of transparency is the following: to the extent that the automated processing [by the web insfrastructure as people go-between] departs from what the author expected, it should do so in a way that is clearly accountable to the user, the other stakeholder with standing in the transaction.  Don't make the transaction suddenly behave as though there is another stakeholder whose interests are being pursued; show clear traceability to the interests of the principals to the transaction.  Always interrupting the user on fault-detection events is overkill; the users will reject this.  So we need a more indirect 'effective control' policy.  But it has to satisfy this top-level transparency requirement; it has to work in a way such that the user is aware of the process and is convinced that they are in command of it.  

It is the user that one appeals to because they are presumed to be more immediately available.  In a real-time collaboration scenario, all parties are available to exercise initiative in establishing a mutually acceptable adjustment in the expected pattern of infrastructure utilization.

Fault tolerance benefits from viewing web transactions as mixed-initiative: the user has the most immediate purview of the transaction and therefore is the supervisor of first resort in controlling fault recovery.  On the other hand, one of the options that must not be ignored is to re-start from a server-side option when such were available upstream in the process which has encountered a fault.

Al

PS:  Having discovered that we are connected with a 'transparency' objective, it is then interesting to try to trace it back to its primitive form, its full force and breadth.  It's not just in fault tolerance applications that this principle comes into play.  The lust for 'rich' interactive media at the surfaces of the Web may be seen to stem from the 'full' aspect of the "full and faithful representation."  The Web is seeking to provide faithful coupling for a fuller representation of human intercourse.

PPS:  Notes for yet another pass at normalization of this development:

High level principle that we need to make more external:

- long-chain composability in service-delivery chains is desired

The chain length is growing, we are realizing that we need to tighten up on the control at each handshake to sustain the good continuity of service [high effective availability with non-trivial non-availability of elements] that the customers have come to expect into this operating regime.

Importable fact from systems science:

- long-chain composability is vulnerable to faults

Derived desideratum:

- resiliency or fault tolerance is good, is sought.

More systems science:

- fault tolerance is achieved by closed-loop feedback control of the pattern of processing
- fault tolerance is best pursued by a multilevel policy seeking to resolve problems as locally as possible.
- fault recovery must be accountable and transparent -- responsive to the same climate of participant/stakeholder interests that govern the transaction in general.



>Keith

Received on Thursday, 30 May 2002 07:48:20 UTC