Welcome to the FAQ for distributed objects! This page attempts to summarize the philosophy, viewpoints, jargon, and ongoing discussions happening on the dist-obj email list.
Our table of Contents:
dist-obj started in June 1996 as FoRR (for "Friends of Ron Resnick (with special attention to Mark Baker too, who didn't think FoMB was very catchy 8-)"), an unoriginal clone of FoRK. Cloning has in the past proven to be a recipe for success where computers are concerned: witness WordStar WordPerfect to Word, or Multics to Unix to Ultrix to HPUX to AIX to Xenix to Linux to myfavoriteix. Good artists copy, better artists steal.
FoRR migrated to Caltech in February 1997 (thanks to Joe Kiniry and the Caltech Infospheres Project), changing its name to dist-obj. Slowly but surely, dist-obj found its niche as a forum for discussing objects (especially distributed objects), seas of components, intelligence, paradox, self reference, metadata, dynamic discovery, safety vs. function, form and ground, implicit and explicit messages, and all kinds of related issues.
Dist-Obj then migrated to the Distributed Coalition (DC) in December, 1998. The DC is the brainchild of the Dist-Obj founders and members of the Infospheres Group.
Normally, new dist-obj members send a "hello, this is who i am" message after listening for a week or two. Try to make the message contain "real" dist-obj content as well. Note that, this rule applies all of the time - if your message doesn't have real content, don't post it. This is a list of over 300 respected professionals and researchers in the field; try not to look dumb permanently in front of all of them.
Recently, the list has considered a few general topics:
D-O (other abbreviations seen include dist-obj, do, DO, distobj, and d-o) is, as stated up front, not intended for the faint at heart. Thus, this FAQ is not intended to babystep you from basics. Still, it should assist those who do want to 'get' the material, but have not been around for the list's entire history.
Dist-obj is not for the timid - there's a certain level of context a reader ought to have for this to be of much use, including:
Also, some listmembers have begun maintaining their own lists o' links, which are decent springboards as well:
Around the same time, in May 1997, Ron Resnick and Adam Rifkin began working on FAQs for this list to serve as a store for a lot of the ideas on the list. We merged them, and Adam agreed to maintain the list. Sandor has agreed to work on a "useful links" page as a companion to this FAQ. We note that this FAQ would not be possible without the contributions of the listmembers and Web surfers. As such, we would appreciate any suggestions to make it better.
Yes, there is one particular post you should read right now. It is the first State of the Mailing List post by the list maintainers and has some important information in it.
D-O is about the emerging world of smart networked bits everywhere in daily life, in business, and in education.
That sentence could have come straight out of Wired! magazine, a Negroponte book, or any New Age TV show about "how information technology is going to change our lives."
By contrast, D-O is about the mapping of the software technologies needed to make this world possible, and about the ramifications of that bit-soaked world. That is, we feel that the Negroponte-like pundits can see the big picture, but are missing out all the technical details of how to make it happen.
Meanwhile, most of the software world, even those highly clueful in their respective specialties in Java, CORBA, and the Web, are often too close to the details to see the big picture (so that they cannot see the forest for the trees).
D-O is about closing that gap: it is about figuring out how componentware, Java Beans, high bandwidth and high latency networks, smart metadata, and object groups, permit the big picture to occur. It is also about illustrating what the big picture looks like, and what that picture means to our lives, to our childrens' lives, to our jobs, to the notion of jobs, to the very fabric of human civilization.
D-O has one or two mottos actually, for depending on who you are they either say the same thing, or they don't. While it doesn't say everything there is to say about D-O, of course, since no single statement possibly could, it captures the gist of it very nicely.
In other words: there's an Orb-like thingie in just about everything, supporting a queryable BO that can do meaningful things? -- Sandor Spruit In other words, there's a HTTP server in every device with a processor and a port which can use PEP and HTML to offer a meaningful, composable interface to any other HTTP client? -- Rohit Khare
We are interested in the really Big Picture of how these technologies change the fabric of organized human life and society and commerce and relationships and work. Do not come to us with "how do I compile my OrbixWeb app?" or "which applets are really cool on Gamelan?" style questions; there are plenty of OTHER good mailing lists and newsgroups for those questions. Mind you, we do talk a lot of technology, but only in how it can be leveraged to support the kind of distributed components we want to build.
(from Ron) FoRR (Friends of Ron Resnick) was the original name of this list, when it got started in the fall of 96. It began as a set of emails between Ron and some friends, and has grown since. When FoRR migrated to its permanent home at the Caltech Infospheres project, the name was changed to Distributed-Objects. We've been looking for a catchier name ever since, but most of us are too busy to give it any thought, so d-o has stuck. 4! was supposed to be a 'cute' alternate for FoRR. Btw, the core of the list membership remains a set of personal friends and acquaintances of Ron. Don't let that deter you though - membership is open to the public, provided you keep to our 'pure bit' policy.
A "shadow" is one of many names for the fundamental "entity" of the digital universe. Shadows can be viewed as everything from programs in the classic sense to components to digital certificates. In general, a shadow is an active technological entity that mirrors and represents a physical entity in the digital realm. We use the term "shadow" as a tribute to Peter Pan.
Ron coined the term "shadow" back in late November of 1996 (quoting):
"BTW, I don't like "cybershadows" particularly - just "shadows", thanks. (For the uninitiated, "shadows" is just yet another word for "component", "business object", "part", "bean", whatever). Why do I need a new one? Well, the imagery comes from the Peter Pan scene where Peter is in Wendy's room trying to reattach his shadow to his foot using soap, and not succeeding. Then Wendy does it using needle & thread. The reason I like it is that that's what is increasingly happening. All our modeled objects (bits) have to get attached to their physical counterparts (atoms),and the art of it is in the "cybertailoring". Think of every physical object in your life as needing its faithful shadow (a networked object, capable of dynamically binding to all the other networked objects as you order it. But these shadows have to be attached, and not with soap, but with the equivalent of 'needle & thread'. There's more elaboration on this in the book, if it ever gets that far, but for now that's the idea and the reasoning for the word."
(from Ron) SOGS= Seas of Gazillion Shadows. It's the whole lot of smart shadows, exchanging metadata and dynamically aggregating and disaggregating everywhere. It's also called the WON (World Object Network) in Infospheres, or the ObjectWeb in the Orfali books (although I think SOGS goes much farther than ObjectWeb in terms of its breadth).
(from Ron) WoT = Web of Trust. It goes hand-in-hand with SOGS, can't really have one without the other. WoT is the sophisticated security/privacy/anonymity/trust model to allow shadows to faithfully represent their owners policies for access, use, etc. In a way, WoT is an extension of ACLs, but with scalpel like precision, and very flexible and intuitive end-user control. There have been a few posts that dealt with the nature of WoT (see, for example, Preeminence and rationality in certain fields of inquiry are no guarantee of lucidity and worthwhile contribution in others. Shockley won a Nobel Prize for the invention of the transistor, but is a total nutcase on eugenics and voluntary sterilization theories. So what does that prove? Only that 'trust' is a very complex thing, and trusting object A on subject alpha doesn't extend to trusting same object A on subject beta. The only way to effectively manage distributed trust with new objects competing for our attention all the time is to build an individualized Web of Trust. That way, if I trust Adam on subject Karma, and Adam tells me that Rohit has good stuff to say on Karma too, I can extend my trust to Rohit. But if I have no reason to trust Adam on subject AlternativeMusic, it means diddly to me that he recommends GreenDay. We do this all the time, implicitly, in analog life. The question is how to formalize and extend and automate the principal in distributed software. The WoT is all about extended associativity of trust. Curiously enough, Rohit and Adam have written a paper on trust for the W3J. The jury's still out as to whether this paper is just about trust models FOR the World Wide Web itself, or if it's also applicable to some future incarnation therein. (Mark) Apollo was the project within Nortel that started Ron and I (and several other dist-objers) on their journey towards Distributed Object Nirvana. Needless to say, we didn't get there. But at least we learned how not to do it. (Ron) Phoenix is a little project Mark & I did in the last couple of months using beans to model some "real" intergalactic components. The name was meant to convey the death of the Apollo project we'd just been on with Nortel (that Gayl, Dave, and Peter were also part of), with Phoenix being literally the "rising from the ashes" - take the same problem domain of Apollo, take the same goals of flexibly interacting components, but just do it RIGHT for chrissake! The general principle being that to do components right, you don't need million dollar budgets, you don't need gazillion developers and managers and architects and testers with gazillion tools and databases and workflows and ORBs and gui builders. And you can't start by saying "we're going to model the enterprise". WRONG! You need a tiny team (Mark & I actually found that 2 of us worked quite well), with tools that the vendors are BEGGING you to use (browsers, OpenDoc, Beans, ActiveX, Infospheres :), and commodity hardware (PCs are dandy). That's it! Spend your time on the *what* of the domain (any domain will do, as long as you can understand it, and someone is interested enough in it to pay for it - in telco this last is a cinch), and not on the *how* of the technology. Don't build your own infrastructure - use the best you can get from out there. And don't expect to have a commercially viable product anytime soon - you won't be able to come to market with robust, reliable, fault tolerant, secure transactional components any sooner than the big guys working feverishly on these problems can't lick these problems. But the moment they DO lick them, in lovely object style, you're ready to take advantage of their solutions. I say, if you start doing the right thing now, in 1996/1997, by the time the underlying infrastructure is out there (security, bandwidth, transactions,etc.) you'll have a good collection of Really Useful Objects (there's that Thomas the Tank Engine thing again) while your dimwitted competition won't even know what hit them. A nickname for the "World Wide Web will solve all your problems" duo of Adam Rifkin and Rohit Khare. They got this nickname because I find karma. Karmakids believe that WIDL (the Web Interface Definition Language), XML (the Web Extensible Markup Language), and PEP (the Protocol Extension Protocol), combined with the notion that "Everything is a Document", are sufficient technologies to build munchkins. PEP has/will have room to grow into into a real sub-TCP, straight over the IP model. Supporting hardware multicast where possible, and routed multicast adaptively? Reliable multicast? VS models? Various ordering and membership guarantees? PEP can evolve to a 'protocol construction kit', permitting on the fly composition of multicast/ p-p flavours, as iBus does? (using URL-based naming to differentiate, no less!) These little future ubiquitous nuggets, which may be related to SOGS, are described in the FoRK faq about munchkins and kudos. The little ol' mailing list that talks about vision, bits, cluons, kudos, munchkins, PEP, XML, and WIDL, described in gargantuan detail in the FoRK faq. Explore the Infospheres Web page and maybe you can tell me. iBus is Silvano Maffeis' baby. (from Ron) I have nothing more against http than I do against IIOP, RMI's wire transport, or pretty much any other TCP based point-to-point. You guys (karmakids on http, Waldo/Arnold on RMI, OMG/Orfali on IIOP) all get so defensive when we take your babies to task... How to make it clear that we're not singling any one of you out for scorn - we hate the lot :-)! Personally, I'd like to start from scratch with a composable framework for protocol construction (something along the lines of iBus), that doesn't have any legacy backwards-compatibility concerns like http et al have. But, if the older transports can grow into what we want cleanly, I can live with that too. Come on! You don't seriously expect an answer here to these, do you? These are all highly relevant on D-O, but they're sort of the prerequisites. A good starting place for some of this is the set of Orfali/Harkey/Edwards books. Try also the papers on JavaSoft's site, and OMG and W3C. Then come back here. (Mark) GiveTake is the term given (by Bill McCarthy, Accounting Professor Extraordinaire) to the fundamental unit of economic interaction. More recently, David Taylor has written about the same pattern, but instead calls it the Universal Exchange. (from Ron) The original Diaper Example was a double-score, since it also contained Sandor's epiphany that became the D-O motto. The Diaper Example was introduced to illustrate the far reach into everyday life that distributed objects would have in a SOGS world. It illustrated a number of themes, such as bits+atoms (disposable diapers have smart shadows attached to them), the low economic threshold at which objects can enter real life (that is, much more than merely smart refrigerators and toasters - much of the literature seems to want to discuss making smart things that already have a certain electrification to them, such as toasters and stereos. What about the truly mundane, like diapers?), the need for ubiquitous wireless networks (since the diaper, like most things, is an untethered device), dynamic binding and query, and more. Of course, it does not, by a long shot, map out the whole space of SOGS. If all SOGS was about was diapers, I doubt any of us would be very interested in it. Rather, it's because SOGS is about so much of everyday life, right down to such pennyante extremes, that it can be reckoned with as a socially changing force. (from Ron) These are activities we all spend a lot of time on. I hate doing most of such 'life-upkeep' chores. One of the reasons is I invariably do less than adequate jobs at them. I burn most things I cook. I mix coloured and white laundry and get those ugly pinks in my white socks. I never remember the right setting on the vacuum cleaner for floors or carpets - does the lever go up or down? Note what's common here: the low-grade informational aspects of these things that I just can't bother to keep track of properly. Nobody would ever bother building a tailor made information system for such things - it really isn't worth the investment. But if there is a network infrastructure in place, and all physical objects 'live' on the network as well as in the real world, then suddenly all that low-grade info can be very efficiently retrieved just at the instant it's needed, and ignored again right after. That's why I like 'boring' examples. Examples of d-o's for mission critical business are easy to find and justify. But these are typically information systems already. They invariably have custom-made proprietary information systems to model them. Rather, the trite examples show the reach of information technology even to aspects of life that could never afford a dedicated 'application'. And, they point to the power of open standards. Because there's no way all those irons and diapers and articles of clothing will talk to each other if they all use a (different) proprietary interface. Closed systems can afford that (although increasingly less so). The pennyante stuff will only happen when *any* object can talk, universally, to *any other* object. Since we spend so much of our life in the trite chores, it's neat to think of all the bits that flow around in them, just waiting to be liberated. The Web today is already a very powerful information-normalizer. You want cheap, trite bits? Look no further! Oodles of them. But the web today still requires access through specialized interfaces - keyboards, mice, screens. If I'm ironing shirts, there's no way I'm going to dial in to my ISP, fire up a browser, access the web page with the entry forms, and for each shirt I throw on the ironing board, type in it's ID, wait for a response from the server, and set the correct temp. setting etc. on the iron. Even though this is doable today - a database of clothing entries per appliance could conceivably be created by the appliance manufacturer. The pain of accessing the bits when they're separated from the atoms is too great. But imagine if the interface to the bits got physically attached to the real world objects. Now the information access is transparent in the course of the activity. The web has to start coming off screen and getting attached to mobile, roaming objects, each with its own network connection, and with smart, bindable, queriable, standardized interfaces. If you have a look at the Karmakids' munchkins, you'll notice a very similar conclusion. The only difference is in some of the jargon - what is *TP? what technology will provide the smart standardized interfaces - XML, or something from the object camp. Answer coming soon... Answer coming soon... Answer coming soon... Answer coming soon... Answer coming soon... Back in the early days of the list, a discussion on chaotic behavior and utility went on. What was at issue was "How will the world use and adopt new elegant technology if packaged correctly?". This led to the following quote: (from Joe) Mark Baker had said: "Utility derives from beauty (you really should have heard Christopher Alexander at OOPSLA), and beauty is typically chaotic. Life is chaotic, so our modelling techniques should be able to capture that. Sims talks about delivering cooperative business objects to 'release the user from the constraints placed upon them by the designer of the software'. This is the key to it all, though it might have more significance than even Sims thought." And Joe responded: "the issue i have with this is that, for the most part, most products of engineering in our field are written by the 97% and thus, no matter how open and beautiful and wonderful the framework/bus/system/whatever is, they'll screw it up. these wonderful plug-and-play, self-aware gizmos will be equivalent to little blind, deaf, and dumb mechanical cockroaches that run up to each other, touch antennae, and vomit."
Godel Escher Bach. As in the Douglas Hofstadter book.
The list is now automatically maintained and the member list is private.
Primarily maintained by the BoDO Crew. Original version written and maintained by Adam Rifkin. Special thanks to Mark Baker, Ron Resnick, and Sandor Spruit for their immense help in compiling this information.
Last modified: Wed Feb 3 23:44:54 PST 1999