KAOS

Hi,

During last Friday’s Framework training session you asked about the “Facet Manager” (FM): whether it was a standard pattern or something that we had just made up. The answer is kind of long but here it is:

The FM is similar to some other patterns, most notably it appears as a combination of the “Product Trader” (PT) and “Extension Object” (EO) patterns. The similarity can even be seen in that an alternate name for the EO pattern is the “Facet Pattern”. The problem with the EO pattern however, is that it stores the facets within the Object itself. This means that it can only work with special “Extensible” Objects and that it isn’t appropriate for large collections of Objects because it would waste a lot of space storing the collection of extensions in each Object. (The silly things people do when they don’t have Contexts. ;-) While these patterns are very similar to the FM, they are not its source; for that we have to go back 15 years…

In 1989 I wanted to write some software to turn my computer into a drum-machine but I didn’t want to have to write all of the low-level code for saving and loading to disk things like drum kits, samples, and scores. I also wanted my drum-machine to be extensible: to accept plug-ins for new features without having to recompile. To this end, I came up with two ideas (I’m still not sure if they are actually two ideas or just one) which have affected how I’ve written software every since.

1. I should make really smart super-Objects and let them take care of all of the dirty work themselves. In the typical OO examples you have something like a BankAccount with methods like deposit() and getBalance() and whatnot. This is fine as far as it goes, but I had much higher ambitions for my Objects. If I could always count on my Objects to know how to do things like load, save, and display themselves, then I could program at a much higher level and concentrate on creating new high-level functionality rather than the unnecessary (from my point of view) low-level mechanics.

2. Code is just a form of data, and as such, should be stored in a database. The analogy that I used was that of a paper phonebook versus an electronic contact database. Both might contain the same information, but the phonebook was statically bound “dead” data and you need to wait a year to get a completely new version containing updates. The database on the other hand is dynamic “living” data comprised of individual records which can be independently added, updated, removed, etc. No need to ship a whole new database just to make a few updates. Also, the phone-book can only be used in one way: to look up a number given a name, but a database is a lot more flexible and can be used for lots of things: find a name given a telephone number, find everyone who lives on my street, find everyone with “pizza” in their name, etc. Conventional software applications are like phonebooks: static, dead and monolithic. Why not store all of the functionality of an application in a database instead and then build a framework to build up the appearance of an application from the components? An application would be essentially just a type of active report. I could add (or replace or remove) new functionality piece-by-piece. Anyone could, not just the original author. I could create custom versions or views of an application for different levels of users: novice, expert, etc. In essence you wouldn’t have distinct applications anymore. You would have a database of Super-Objects and features for them: different file formats, utilities, viewers, etc. A paint program would instead just be an Image Object with a whole collection of file formats, effects and transforms made available through menu-items, toolbars, and other UI features.

I realized that with such a system I wouldn’t need any more applications (no more phonebooks). This would be the last program I would ever have to write (I would just extend it forever). I figured that it would actually be a form of OO OS so I called it KAOS (Kevin’s Amazing Operating System). Unlike other OS’s, its smallest unit of code would be much smaller than a .EXE and it wouldn’t need any file formats because the Objects would take care of that themselves.

In the fifteen years since then I’ve written more than ten major versions of the KAOS idea (counting all XHome’s as just one). At the heart of most of these systems was a database of things like: Objects, Object Features (Facets), Menus, Actions, Services, Pipeline Configurations, etc. The database supported pattern matching so that you could do things like: “find all menus with this menu as a parent” or “find all actions suitable for this Object” or “all Views suitable for this one”. The last version of this unified database was called eSpace. Here’s the interesting part: it was the Context, Facet Manager, Action Manager, L&F Manager (something like our current Message Manager and Renderers), and XMenu Service, all in one. So the real answer to your question is that the Facet Manager was broken out of the Context about five years ago. Prior to that, it had never been a separate feature; and neither had most of other major services.

I would like to say that I had some brilliant reason for changing the design to its current more modular one, but the truth was that it was just an experiment. Over they years the eSpace had been getting larger and larger (it supported callbacks, journalled persistence, synchronization and client-server or peer-to-peer networking) so I was curious if I could make a real simple canonical version and then add the extra features as extensions. When I finished moving everything from the eSpace to external services (placed within the eSpace), I noticed that it looked a lot like Sun’s planned “beancontext” system so I renamed it to Context to give it a similar naming policy (in a similar way “Homes” were renamed from “Soups” because of their similarity to EJB Homes). The current design just happens to be how it was when I came to XX so that is how it still is. (While I did it as an experiment, I can safely say now that the results are in and that I know the advantages and disadvantages of the two schemes:

1. The all-in-one eSpace design was actually a lot less code because I didn’t need a new service for each new type of Object. It was in a way simpler because you only had one screen to configure everything but it provided less-guidance because of it.

2. The Context and extensions design is better suited for client/server (like here at XX) because the individual services are much faster that the generic pattern matching system (with only one user you don’t need to worry about it but with thousands of users hundreds of transactions per second it becomes an issue). This method also fixed a problem that the previous versions had with pattern-matching and inheritance. In the face of partial matches across multiple inheritance levels, in can be difficult (impossible?) to come up with a suitable policy.

Well, that is a little more detail than I had planned but the point is that the FM is something that I invented, fairly recently, as an obvious spin-off of functionality which had previously been build into the Context as a means of realizing my design for a code database.

Regards,

KGR

---

The point is that the Context, Facet Mgr, Action Mgr, Message Mgr, COMICS, XMenus, etc., are all actually instances or components of a larger pattern. That pattern is about being extensible and modular by being object-driven (like data-driven but with Objects (I just made up the term so any other uses are either unrelated or coincidental)).

Definition:

A data driven architecture/language performs computations in an order dictated by data dependencies. Two kinds of data driven computation are dataflow and demand driven.

Data-driven also includes things like XML-based GUI’s (XUL) and table-driven parsers (like yacc).