Distilled Network Mobility -- Patterns in Network Architecture: A Return to Fundamentals

I was browsing through a network mobility resource in oreilly safari ...

BOOK

Patterns in Network Architecture: A Return to Fundamentals

By John Day

Table of Contents

... this book describes to a T the fundamentals of a distributed and mobile object namespace though tends to get irate about certain EITF shortcomings...

but the fact is that an IPv4 address with or without the euphamism of DNS is about as mobile as a tree-root. IPV4 traps the essence of distributed and mobile agent systems from all but the very highest layers of abstractions. I'm not sure I ever counted the number of abstractions rolled into one dissertation of a fused enterprise bus/mobile-distributed agent and namespace/high performance supercomputing swarm platform...

...the world of standards operates in concrete and encapsulated terms that number in the dozens when considering the challenges faced to mobilize code (web isn't even in the same ballpark, or more than a transient conduit) on an ipv4 baseline network... over the years I've seen language developing around concepts far too vastly compounded and complex to iterate when i first started employing these concepts. The language I've used to date is typically as terse as is necessary to pitch products with the benefits built in from patterning after the idealized distributed agent models, however only 1 in 1000's of software professionals or funding sources i've met has voiced or acted on any significant understandings and championing of mobile software agents.

...I found an interesting excerpt that describes the engineering process in general, and very strongly describes nearly every project I've contributed innovations into... I'd liken these analogous to metaphors of hunters and farmers.. or perhaps the options seekers vs. the procedural mindsets.

from John Day's book...

'If one looks carefully over this chronology, one is inexorably drawn to the conclusion that the Internet did not begin to stagnate at the turn of the century, but in the late 1970s. It is here that conservative behavior begins to take hold. It is here that each juncture is not seen as an opportunity to fulfill the earlier vision or to synthesize new insights with previous achievements to create a new innovative direction, but more the minimal change is made to solve the immediate problem and go no further. It begins to seem that people are the keepers of some flame and dare not tamper with what has been entrusted to them, the classic behavior of a "second generation" i.e., not the founding generation. Some will argue that this was the policy of small incremental change that has been a stalwart of Internet development. And they are right; caution in maintaining a production system is a necessity but a slow death for research and the research was far from done. But isn't that just what one would expect from the inheritors of the flame? Is that just a rationalization of a much deeper malaise?'

while I'm not really as incensed as John Day about the challenges of ipv4 or the common theme that those who seek job security often shy from loving their work, I do like the blunt picture of futility vetted succinctly and concisely in one chapter of a book underscoring the challenges of building 'timeless' software agent designs in a stunted and self-afflicted problem domain.

• Stateless infrastructure stands a better chance of being flawless software foundation than API counterparts which exist as islands of similar base classes.
  
• Databases are the doorstep of an enterprise, hardly the foundation, and boy can Oracle screw up a simple socket data delivery design...
  
• The business plan is in the hands of its engineers.