More on automated interfaces

• UNIX philosophy of universal read, write, create (sic), seek verbs is akin to financial transactions, where bytes are analogous to money
• HTTP extended this with POST and made it stateless - so it becomes a client-server protocol (a good alternative to X-Windows by the way)
• The universal currency is data, and it can contain anything, it can buy anything. Putting meaning to it is really the difficult part, and the notion of objects is really an attempt at creating a philosophy of data
• Right now we have an inflation of data, too much currency, and its value is being balkanized, some currencies are more precious than others, security related ones, and maybe some video or music bytes. Copyright is an attempt at increasing the value of bytes through currency control.
• So if an object defines the methods we can use to manipulate it, then one way to have objects communicate more easily (ideally automatically) is to constrain what objects can do to a machine manageable set. This may not be much of a constraint, only one that promotes efficiency through consistency.
• Or we can take the idea behind types to heart and have a huge catalog of types and ensure that they can play together - real types which map to useful objects
• For example, a user at any terminal could drop select from a list of things like ADDRESS CHANGE, VALIDATE ID, SUBMIT CLAIM, BUY, COMPLAIN, CHANGE FIELD, etc
• This is the "naked object" philosophy taken one step further. No need for a graphical interface, just a nice "no error" interface - where all choices that work are shown. The "trie" of possibilities would reduce itself as transactions are chosen to interact, limiting the choices the more you decide
• In short, modeling. Can this work in an ad-hoc world? Maybe the modeling should be automated through affinity and tuple-space approaches to ad-hoc property lists
• This, coupled with a hierarchy of state machines (like game play AI) would go a long way to creating automated interface coupling.