NetScape's Internet Foundation Classes and Marimba's Bongo

Don Hopkins, Interval Research Corporation

This is a comparison of two component frameworks for Java, IFC and Bongo.

IFC (Internet Foundation Classes) is from NetScape, and is similar NeXTStep, which was written in Objective C. It was written by some former NeXT developers, whose company NetScape bought because they needed a Java toolkit.

Bongo is from Marimba, and is similar to HyperLook, which was written in NeWS object oriented PostScript. Marimba was founded by some of the original Sun Java developers, who left Sun to form their own company.

Arthur van Hoff is the architect of Bongo. He also designed HyperLook at the Turing Institute, and wrote the Java compiler and designed AWT at First Person. Other parts of it, like the text editor, were written by Jonathan Payne. He also wrote Jove when he was in high school, designed the original HotJava browser at First Person, and worked on Java at StarWave.

Bongo is quite fresh and clean, has a lot of great ideas in it, and it is very well matched with Java; but it still has a long way to go.

In summary, I think it was too early to write a Java toolkit before JDK 1.1, so IFC has gone and done a lot of its own stuff, which will have to be drastically changed to take advantage of the new stuff. Bongo is not as far down the road of painting itself into a corner like that, and if some effort is put into it, to bring it up to date with the new facilities in Java, I think it will be a better framework than IFC. Java Beans remains a big unknown, that I don't have a lot of faith in. Arthur says Java Beans does too much, and I'm afraid it may try to push competing frameworks like IFC and Bongo out of the limelight, instead of just providing a low level substrate on top of which they can interoperate (like the TNT ClassCanvas). If Bongo can pull off ActiveX integration with style and grace, then it wins hands down, because I doubt IFC can, and I don't trust Sun to deliver on their promises to do that with Java Beans.

IFC's Target notification model is cheezy, based on command strings. OLE at least provides a way to bind names to more efficient tokens. There's no way for components to expose metadata about the notification messages they handle, except by the "ExtentedTarget" interface that only lets you ask about particular messages, but doesn't give you a list of messages. In some cases, like text fields, it blurs the concept of querying if an object responds to a message, with the concept of querying if an object is editable, selectable, etc. That is, if the object is not currently editable or selectable, and you ask it if it can respond to the paste or copy messages, it replies no. It should expose those properties directly instead of indirectly communicating that state through the ExtendedTarget canPerformCommand method. Don't confuse class metadata with object state.

It must be possible for any component to send any message to any other component. This is why IFC has resorted to message strings, because static Java interfaces do not support the run-time binding necessary to support data driven message dispatching. The IFC documention puts it this way: "To be easily reusable, an object must be able to send an arbitrary message to another object without knowing the type of the receiving object."

Bongo does not have a message dispatching interface, so handlers invoke methods directly instead, which works because the script editor dynamically compiles Java code that defines handlers and can send any message to any object.

Bongo exposes metadata about component properties through its persistence mechanism's "getProperties" method. IFC has a similar persistence mechanism, but Bongo's exports somewhat higher level information about the properties [like enumerated type choices], and its method for getting property values has a default value argument in case the value is not defined.

The Bongo interface editor's property sheet gets the names and values (as well as metadata like enumerated choice mappings from names to numbers), through the getProperties method. This approach, combining persistence with user level property metadata, kills two related birds in the same bush with one stone. But it could support even higher level metadata about the properties (like value ranges and constraints, higher level data types like time, etc.), as well as a way of relating custom property sheets and editors to properties.

For example, to edit the four numeric properties that glue the edges of a component to the parent, a property sheet could display a widget that let you directly manipulate all four values at once by clicking and dragging a graphical representation. It would be great to have a general mechanism for associating specialized editors (like position, size, color or font) with one or more component properties. Imagine a foreground and background color editor that enforces the constraint that the two colors contrast, with a Mr. Yuck / Smiley Face that tells you if the colors match.

Bongo lacks the inter-component "Send" facility that its predecesor HyperLook supported, which delegates unknown messages from component, to card, to background, to stack, and then over the net to the application. HyperLook's "Send" delegation model was based on HyperCard's messaging model, with an extra outer layer for the remote client). It would be nice to have a mechanism that integrates nicely with Castanet messaging, and also makes it easy to encapsulate a bongo presentation and handle the high level messages that it generates.

You also need to be able to ask an object what messages it supports, as well as what properties it has. IFC lets you ask an object if it supports a particular message string, but confuses the issue with the state of the object and preconditions of the message (i.e. the formal precondition of the cut message should be that the component is editable, and that something is selected; but instead, it just claims that it doesn't respond to the cut message, if the conditions are not met). How could a message browser or visual programming tool know that it was some times possible to send a particular message?

IFC doesn't have a way to enumerate the message strings an object supports. Bongo doesn't provide that either, but it does have a single interface for reflecting and persisting the properties of an object. Bongo doesn't have a separate message interface, because it doesn't have a problem sending any message to any object, since it uses a script compiler. Bongo would be better off using the upcoming Java reflection interface than inventing its own ad-hoc anemic messaging interface, like IFC.

JDK 1.1 has support for reflection, that addresses some of these problems, but not all, since there is more interesting higher level metadata that components need to expose, than just the Java class information that reflection exposes. It's probably not the right level of abstraction to support inter-component communication like OLE's dispatch interface and connectable object interface. Java reflection lets you get a handle on and invoke any method of any object, but it's too indirect to be useful for efficient everyday message notification. It's more like what a debugger/inspector would need. It would be great if it were possible to associate other high level user oriented metadata with Java classes, methods, and members. There is a recent extension to OLE type libraries that supports just this, but such a facility needs to be directly supported at the level of interface specification languages like MIDL or IDL.

The JDK 1.1 reflection interface is too low level to directly support all the needs of a high level component framework like ActiveX. A user level component does not necessarily want to expose every method and instance variable to the user.

Components need to expose higher level information about the intent behind and associations between properties and methods, like grouping them into categories, specifying ranges and constraints, preconditions and postconditions, associating values with enumerated types and meaningful labels, as well as invoking custom property sheets and editors.

For example, even though the draw method needs to be public, so the component container hierarchy can display itself, there is no need to expose it to the user or other components than its parent. One component should not need to notify other non-child components to draw. It should be up to a component to maintain its visual consistency, so if you need to tell it to draw from outside, something must be broken.

OLE provides a way that components can expose a set of user visible properties and methods that are relevent to the user (like a visual basic programmer or web page designer) who plugs them together, but they hide the gorey implementation details of all the low level interfaces.

Bongo and IFC make it possible to expose and persist only a subset of a component's instance variables, so internal run time state can be hidden from the user. For example, there's no reason to persist or let the user edit the boolean flag used to blink a text field's cursor on and off.

It would be more efficient for IFC to use tokens or atoms instead of strings as messages, and allow components to expose and register their interests, so the target hierarchy does not have to be searched all the time, and messages can be directly and efficiently delivered to the interested parties. It should be more data driven, instead of requiring programmers to write "switch" and cascading "if" statements with lots of magic embeded literals.

On the other hand, there's another approach that takes the higher road. OLE's connectable objects interface provides a formal way to use interfaces to connect objects together, and reflect on the possible and actual interfaces and connections, without the runtime binding overhead of IDispatch. This allows objects to invoke each other very efficiently through direct interfaces, while making it possible to enumerate all the connected objects and possible outgoing interfaces. The task of obtaining metadata about those interfaces is a separate problem that type libraries address, in a rather heavy-handed way.

I don't think the string based message notification system of IFC will scale up very well, or support sophisticated interface editors, inspectors, high level components, scripting, and visual programming environments. It looks more like it was designed for a non-object oriented system written in C, instead of for Java, since it makes a weak attempt to solve some of the problems that can be addressed much more formally and completely in an object oriented quazi-dynamic language like Java.

Bongo, although it doesn't yet have its own message delegation mechanism, has a cleaner slate on which to draw. It might be a good thing that Marimba did not design their own messaging mechanism before JDK 1.1 was released, so they can be take advantage of the new language features, like reflection. The fact that Bongo is based around a dynamic script compiler allows it to side-step some of the problems that complicate IFC: instead of comparing message name strings at run time, the Java compiler binds message names to interface methods at script compile time!

Bongo's persistence mechanism is a good start in the right direction, but a higher level message notification and delegation mechanism needs to be designed and implemented, in light of the recent additions to the Java language.

Bongo supports inheriting properties like colors and fonts from the containment hierarchy, as well as the class hierarchy. Container inheritence lets components dynamically inherit their properties from their parent containers. It's a very useful mechanism, that makes it easier to plug together components and saves memory. IFC doesn't seem to support container inheritence. Even OLE has a way for components to inherit properties from their container.

IFC ContainerViews should be lazy about creating their title text fields. Wouldn't it be more efficient if they drew their titles directly, instead of adding another subview to themselves. It clutters up the container hierarchy. How does the persistance mechanism know to treat that programatically created text field subView differently than any other subViews? It has to be handled specially in encode.

ScriptX and Bongo containers have a container class with a separate "contents" instance variable for the "user level contents" of a container, and accessors for adding and removing components to that. This is because many containers, like scrolling lists and windows, need an extra level of containment to encapsulate their own components (like title bars, close buttons, scroll bars, etc), separate from the grouping container that holds their contents. For example, to implement a scrolling panel, you would not want to put the scroll bars inside the sub-view that they scroll around. Instead, the panel view contains two scroll bars and another sub-view, which contains yet another "contents" sub-sub-view, two levels deep. When you scroll the scrollbars, they simply change the location of the "contents" sub-sub-view inside the sub-view, so all the contained widgets scroll together, the scroll bars stay in one place, and the sub-view properly clips the sub-sub-view. When you add a sub-component to the scrolling view, you want it to go two levels of containment deeper than the top level scrolling container, so it's necessary to distinguish the "user level" container from the "implementation level" container at the container API level.

Every Bongo widget can contain other sub-widgets, but there's a special "ContainerWidget" class that introduces the "user level" containment methods. For simple un-adorned single level containers like the "GroupWidget", the user level "container" just refers directly to "this".

IFC doesn't make such a distinction, so its adorned containers (like windows) must have a less than honest API with special purpose code to manage title bars, scroll bars, etc, which makes them much harder to subclass and customize.

Here's an IFC bug: DragView startAnimatingRejectedDrag doesn't seem to animate back if dragged diagonally (deltaX == deltaY). It looks like a bug: a fence instead of post. It meant to executes the "don't animate back because already there" case only if ((deltaX == 0) && (deltaY == 0)) but instead executes it if (deltaX == deltaY).

IFC's FoundationApplet class: This pushIFCContext / popIFCContext stuff is gross and out of hand. There must be a better way. Why does IFC need the currentApplication method on the FoundationApplet class anyway? Is there a cleaner more general way to solve this problem, that won't break down when there are multiple interpreters installed, like Internet Explorer can do with JScript, Java, VBScript, and other languages (by plugging languages in through the IScriptingEngine interface).

IFC's The following Graphics class variable initializations look pretty suspiscious:
static int graphicsCount = 0;
int graphicsID = graphicsCount++;

IFC's drawRect & drawRoundedRect & drawOval [but not drawArc or drawPolygon!] subtract 1 from width and height before passing them on to awt, which presumably draws X11 style rectangles with "bonus pixels" one wider and taller than filled rectangles [see the Unix-Haters X-Windows chapter]. There is a reason for drawing shape outlines "half opened" in the X11 pixel model, which is fundamentally different from the PostScript stencil paint model. People will be suprized when they port their AWT and X11 code and it draws incorrectly. Like it or not, AWT is pixel oriented, so until you provide a full blown PostScript imaging model, it's a bad idea to change the drawing semantics of the graphics interface, without changing the method names. This difference from AWT should at least be highlighted in the IFC documentation. It's strange that DrawArc was left out, so people drawing pie charts may be confused, but of course there's no way to apply this hack to DrawPolygon.

Glyph fonts and image sequences would be a lot more memory efficient if IFC did not break them up into a whole bunch of tiny bitmaps, but kept just one big bitmap, and a bunch of rectangles of the characters in the bitmap (in a flat scalar array), then use a bitmap drawing primitive that draws a sub-rectangle of a bitmap, without requiring you to use clipping. Please add such a primitive to your graphics interface if it's not there already, since it's extremely useful for fast memory efficient animation.

IFC's it would be nice to have a "Background" layer defined behind the "Default" layer.

IFC's _mouseDown filters out mouse button chords. Ignores second down event in a row, so _mouseUp triggers on either of the two buttons being released. It's like pretending there's only one moue button, when the user knows otherwise. It confuses users and throws away information the interface designer might need. The API should distinguish the buttons and make it possible to write robust mouse tracking code that can correctly track the state of the input device. Xerox's XDE used button chording as a shortcut. Some window managers allow you to cancel an operation by chording. Interactive interfaces might assign an orthogonal function to each button (for example, a music program or a game), so they must be able to track both buttons independently.

IFC's wantsMouseEventCoalescing: It's nice that IFC has a way for views to turn off mouse motion collapsing during mouse tracking, or whenever the cursor is in their region. This is necessary for drawing tools, and interfaces that respond to gesture without the button pressed.

All those hacks for modal view event handling are horrible. Modal dialogs should go. I am of the strong opinion that the toolkit should not bend over backwards to support this dubious style of interaction. It once made sense to the programmers of single threaded event driven Mac applications, where each modality was implemented by the program counter in yet another event handling loop. Modal dialogs don't make sense to users, though; a fact lost of most single threaded programmers who take modal dialogs for granted because they naturally follow from that outdated style of programming. If you want part of the interface to go inactive, then just remove it from the screen, so it's not possible for users to see it, click on it, or be confused and frustrated by it.

Simply use better metaphores than modal dialogs, like tabbed pages, stacks of cards, or outliner trees. Wouldn't it be easier to just implement tabbed pages and stuff like that as modular reusable components, instead of massively complicating the event distribution mechanism at a low level in order to simulated the toxic side effects a single threaded system? By corrupting the toolkit with modal dialog support, instead of offering alternatives, IFC is encouraging bad interface style, instead of making it easy to create good interfaces, and all programmers and users must pay the price of complexity and frustration.

The classic example is the tree of deeply nested modal dialogs of Windows 95 device driver control panels, that pop up so many overlapping levels of beveled panels that it looks like an overhead view of the Mayan temples. There are so many identical "OK" and "Cancel" buttons visible on the screen at the same time, that you must visually climb the steps to the top of of the highest temple in order to escape.

IFC's Hashtable, Vector, Enumeration, VectorEnumerator, Comparable, Point, Rect, Size, Sort, Timer, LayoutManager: Why does IFC need its all of its own basic classes, that already exist in Java? Probably because persistence is not implemented by the system, and it has to be explicitly coded into every IFC class.

IFC's Graphics, Bitmap, Sound, Color, Event, Font: These are all wrappers around AWT classes. They provide some utilities and convenience functions, but not much in the way of higher level abstractions, to justify yet another layer all around.

IFC's and the whole concept of IFC wrapping AWT classes in its own classes: This is quite inefficient in terms of memory and speed and learning curve. It might seem worth it to insulate programmers from complexities and drastic changes in Java's awt, if only IFC provided a substantially higher level of abstraction, like a PostScript-like imaging model and stuff like that, the way Galaxy does (or Jive or Vibe or Bile or whatever it's called now). But in some cases, the IFC wrappers around AWT and other standard Java stuff don't even add any functionality, they just implement persistence (the Codable interface), which is a problem that should be solved at a system level (which will be done by Sun, incompatibly with IFC).

IFC's Scrollbars would be faster and smaller if they implemented the increase and decrease buttons directly, instead of making two separate objects per scrollbar.

IFC's performCommandLater is somewhat over-object-oriented, and probably pretty slow. I hope it's not used a lot.

IFC's run length encodes a bunch of bitmaps used by the system. This points to the lack of a reliable solution to the resource problem. Why isn't there a mechanism for packaging gif images and other resources with java code, instead of resorting to this.

IFC's I think the word they were looking for is "Bevel", not "Bezel". A "bezel" is the beveled edge of a cutting tool, or a part of jewelery where gems are attached, or a groove that holds a watch crystal. A "bevel" is a slanted edge in general, a more common and appropriate word. I asked several people if they knew what a Bezel is, and only one knew the jewelry mount connotation, but they all knew what a Bevel is.

By the way, please don't use "cute" method names like "blur" as the opposite of "focus". Ha ha ha not.

IFC's _keyDown has a huge cascade of if tests like: "if (event.isReturnKey()) { ... } else if (event.isLeftArrowKey()) { ... } else if ..." This is a really inefficient way to handle events. It should at least check for the most common case of event.isPrintableKey() first, but that test is the next to last!

IFC's DrawingSequenceOwner, InternalWindowOwner, ScrollBarOwner, TextFieldOwner, TextViewOwner, WindowOwner, DrawingSequenceOwner, and TextFieldOwner: why do all these special interfaces exist, instead of using the message sending mechanism? (For what it's worth, or is the Target interface inadequate)?

IFC's ExtendedTarget is only implemented by TextView, RootView, and TargetChain. The static message name strings like ExtendedTarget.SET_FONT might save a little bit of memory by sharing a few strings, but what about the memory it takes to have yet another symbol (with a string for the SET_FONT name)? It doesn't seem like a very general or far sighted approach. The only thing ExtendedTarget seems to be used for, is bringing up font and color choosers (and I don't understand why there has to be a special message to do that), and dynamically changing the target of a menu of generic commands (like cut/copy/paste). But TextField doesn't implement ExtendedTarget, so it can't be the target of a menu's "cut" message. There are other ways to dynamically target menus. I don't believe that the complicated ExtendedTarget delegation stuff is really all that useful. A simpler more efficient model would suffice.

It would be nice to be able to name components, address nested components by path names, and search for components by name. That would be easier to understand and more useful than the delegation implemented by TargetChain.

IFC's ExtendedComponent: No classes implement this yet. This interface enables components to be edited by the user interface builder. Since the user interface editor does not exist in this release of IFC, I don't know if it's necessary for a component to implement this interface in order to be editable. It be would be preferable if all components were equally editable.

IFC's addFieldInfo: This tells which modifier key must be held down to set this field via a drag-and-drop operation. This is too low level device specific. It should describe the semantics at a higher level, so the interface builder can be reconfigured, and can also make higher level decisions about which property editor to use. Instead of hardwiring the toolkit to require the user to hold down certain modifier keys, why not just put two drop targets into the property sheet, one for each purpose? Then users would be able to see that they had an option (even if they didn't have an option key).

IFC's addFieldEnumeration: This associates an enumeration with a field. It has a modifier parameter that specifies LIST or POPUP. This is too low level. The interface builder should be able to choose a representation based on the size of the array and user preference. The metadata should describe the data at a high level, not the user interface at a low level.

All the command interpretation and reflection stuff should be driven off of the BuilderInfo metadata, instead of special purpose methods. They could have made one class that implements BuilderInfo and the command dispatching stuff, driven by data instead of code, dispatching into message handlers with efficient integer indexed switch statement.

Or define message objects that can be directly executed efficiently, and use hash tables to map strings to them. Anything but these cascades of string comparisons scattered all around the code.

Why is there a separate encode and builderEncode? This stuff should be done one time in one place, driven by data, otherwise it's easy for code to become inconsistent.

For example, in, why does "encode" not write out "isBuffered", while "builderEncode" does? If it's a bug, then it illustrates the maintainence problems of writing everything twice. If there is some reason that isBuffered is special and should be editable but not persisted, then that should be communicated via a flag in the metadata.

By requiring people to code all this metadata into their programs, IFC goes the route of OLE [the MFC implementation], but without the macro preprocessor. The MFC C/C++ implementation of OLE uses CPP macros to concisely encode metadata as static data in programs. You may think OLE code looks gross, but it's actually quite concentrated compared to what it would have to look like, without a macro preprocessor. And those nasty macros can be machine generated.

But since IFC is written in Java, programmers are going to have to laboriously code and (worse yet) maintain all that scaffolding in straight Java. Compared to OLE, IFC is up a very deep creek without a paddle, and heading for a waterfall. The outboard motor that drives Microsoft's integration of ActiveX/Java is MIDL, which clamps onto all kinds of other boats as well, and generates type libraries, interface stubs, all those nasty macros, etc...

Why doesn't IFC use CORBA's IDL, or at least the new Java reflection interfaces, instead of coding metadata directly into programs? Or why not use MIDL?

All this talk about how CORBA's going to take over the world (oops, I mean save the world), but nobody's actually using it. Just talk, talk, talk, while Microsoft is actually systematically using their own shit. I've even heard CORBA fanatics bragging about how long they've been bragging about it! So where is it??! You can't get something to work without using it, especially if all you do is spend your time talking and making promises, deals, press releases, and consortiums, instead of writing real code; that's why there's no hope for CORBA -- it's far too late.

Unfortunatly for NetScape, the best thing they could do would be to swallow their pride and embrace ActiveX and MIDL, just like Microsoft "knuckled under" and stole the Java ball away from NetScape (after NetScape had just stolen it away from Sun).

The 100% Pure White Java Supremicists don't seem to think that a user interface component toolkit that locks you into one language is "closed", or a component object model that allows different languages to interoperate is "opened".

They think integrating Java and ActiveX is "impure", while integrating Java and CORBA is "pure". They are so hysterically anti-Microsoft, that they cripple themselves with self-imposed ignorance and abstinance of Microsoft technology, afraid they'll lose their faith if they learn what they're up against. They're so proud of their own cleverness that they refuse to acknowledge or steal any of Microsoft's good ideas, then they invoke Hitler and Satan whenever Microsoft flatters them by immitation. Communism might be bad, but so is McCarthyism.

ActiveX COM interfaces are described in MIDL, Microsoft's Interface Definition Language. So you write all the high level metadata once in MIDL, instead embeding it in one particular implementation language, useless and inaccessable from other languages.

MIDL is a mish-mash of interface definition languages, accreted over time, covering the definition of classes, interfaces, method signatures, enumerated types, safe arrays, all C++ data types, DCOM interfaces, OLE dispatch interfaces, OLE properties, data binding, etc.

MIDL compiles into binary type libraries, which are directly understood by the J++ VM, so COM interfaces are mapped to Java interfaces (or the other way around, depending on how you view it).

The stuff in type libraries is of interest to interface builders (Visual Basic), dynamic programming languages (VBScript, JScript and J++), persistence mechanisms (ActiveX storage), and remote procedure call facilities (DCOM).

There's a somewhat recent extension to type libraries that allows you to associate arbitrary GUID-tagged data with any element in the library. Like application-defined meta-meta-data. But I don't believe there's a MIDL syntax to support this type library extension yet. But MIDL is not the only way of generating type libraries. There are COM interfaces for reading and writing type libraries directly, so you never have to parse MIDL.

Like the situation with all the incompatible Java native code interfaces, the Java metadata situation is totally fragmented and blocking on Sun to invalidate all work done so far, while Microsoft has been developing and deploying a viable alternative for years (COM and type libraries).

There needs to be one coherent solution to metadata, so you can describe interfaces cleanly in one place, which everything else depends on.

If NetScape is serious about CORBA and OpenDoc, and directly opposing Microsoft's every move (which seems to be the reflexive company line), then they should use CORBA's IDL to describe interfaces. Sun's certainly working on the problem, if you think their solution will be good enough to depend on, and you want to wait. But of course it's a matter of too little too late, since Microsoft already has their ActiveX infrastructure in place, with a high quality J++ VM that supports ActiveX interfaces type librararies directly.

(By "infrastructure", I mean important things like glossy magazines for sale in Tower Books chock full of colorful ads for all kinds of plug-in components -- a real live competitive OLE component industry is already entrenched, and that's what counts in the long run.)

NetScape is going off in all directions at once with component technology: CORBA, OpenDoc, Applets, Java Beans, Castanet, IFC, Navigator Plug-ins, ActiveX, their own Java native method interface, etc. But they don't have the sheer mass to support so many incompatible strategies, like Microsoft does.

The CORBA camp is totally fragmented, with only a lukewarm endorsment of OpenDoc, their only hope, so that petty rivaling companies can stick to their own competing technologies, like the IFC -vs- Java Beans -vs- Bongo fight that's going to piss away so much energy, and piss off so many potential developers. Remember when Fresco was the next big thing, so nobody in the Unix camp payed any attention to OpenDoc? Now where is it? I'll bet some poor sod is rewriting it in Java, so they can at least re-use their marketing literature.

So, why would Sun help port OpenDoc to Unix when they could scuttle it with their Java Beans announcement? Java Bean Vapour has effectively put the design of all other Java toolkits like IFC and Bongo on hold, and will probably require large parts of them to be substantially redesigned! It tries to do far too much, not to interfere with all other Java toolkits, and way too much for Sun to competently implement.

Meanwhile Microsoft isn't waiting for Sun; they're tightly focused on integrating Java with ActiveX and DCOM on Win32, Mac, and Unix. And they aren't timidly keeping it secret.

OpenDoc is based on SOM, not DSOM, so it isn't distributed. SOM and DSOM are not even source code compatibile -- they have fundamentally different models and capabilities. IBM gave up on DSOM, leaving it up to someone else to bind OpenDoc to CORBA, since they've got their hands full porting OpenDoc to Windows. So even when the OpenDoc port to Windows is finally finished [and doesn't require you to buy IBM's expensive compiler to develop components], there will still be no link between OpenDoc and CORBA, since the efforts are splintered. Meanwhile ActiveX and DCOM are already here.

OpenDoc has dreams of engulfing Java Beans, but so far there's just a CyberDog applet viewer, but real Java access to OpenDoc is just on the drawing board. When will you be able to write an OpenDoc part in Java, or use a Java Bean from OpenDoc? Can Java and SOM be integrated as tightly and efficiently as Java and COM? I highly doubt it, since SOM is overly complex in unnecessary ways that don't matter to Java. Meanwhile ActiveX and Java can already interoperate in J++, and MetroWerks and Microsoft are colaborating to save the Mac platform from Apple's own vanity, by integrating Java and ActiveX on the Mac. Steve Jobs and his obsolete version of Unix [an old Mach with classic 4.2 interfaces] aren't going to save Apple, and the deal sure isn't a good sign for OpenDoc.

Java Beans has dreams of engulfing OpenDoc, as well as ActiveX. Which will engulf the other first? Look at how much trouble Word Perfect, Novel, and now IBM have had integrating just OpenDoc and OLE! Now Sun promises to integrate all three to an even lower common denominator. When they get around to it. Any way it comes out, it will be horrible. I refer you to Exhibit A, Sun's original SunView Directions Statement, claiming they would integrate SunView with NeWS; and Exhibit B, Sun's X11/NeWS merged window system, demonstrating how bad it finally turned out, many years later.

One of the unavoidable laws of the universe is that each component framework does its damnedest to cripple any other it comes in contact with. They are, by their very nature, moving targets in different directions. Any effort spend on integration will always takes a long time, will be fat and slow and buggy, and will be hopelessly inadequate and out of date by the time it's delivered.

The worst thing that could happen would be if all those component frameworks engulfed each other. Why would anybody want to have n factorial sets of interoperability glue loaded and tangled together in memory all at once? There wouldn't be any time or space left to do anything at all -- just a big messy wad of staples and glue and tape and nails and string and plaster and magnets and paper clips and velcro and thumb tacks and bandaids and epoxy and crazy glue and bondo and rubber cement and suction cups and tinker toys!

Date: Wed, 15 Jan 1997 16:38:09 -0500
From: "Tim Triemstra" <>
Organization: Alpha Star International
Subject: Re: IFC Integration in Bongo?

Klaas Waslander wrote:

...the IFC model uses a new graphical model instead of the AWT which makes it something totally different. We built on top of the AWT which makes it better compatible with standard Java. So you can imagine the two things, Bongo and IFC, are incompatible. Of course it is possible to work to one standard, but that would especially require IFC to work towards the AWT or at least change things there. We do not like the fact that it is separate from the AWT and there are also issues with the look and feel of their user interface.

I was of the impression that Bongo looks the same cross platform - I could be WAY off base on that one because freely admit I haven't tried anything but the Windows distribution yet. If that is the case, how tightly integrated to the AWT could it be (I also remember comments that the peer code was different or not there.) I personally am 100% in favor of having at lease the option to deploy with a single style user interface, althoug I see the advantage of system native looks as well (and would prefer to avoid that arguement here.) I only really bring the IFC here because it looks like Sun is taking the IFC very seriously and an interview with one of the Marimba bigshots (sorry, not good with names) made mention of how the Bongo future looked bleak for a while because of the purchase of Netcode (I believe) who was doing something very similar which turned into the IFC. My history on this may be wrong aas well, but if it is indeed Netcode, I seem to recall that they had something similar to the presentation (or NeXT's .NIB) metophore implemented. This seems direct competition and with the alliances with Marimba and Netscape this seems to be a conflict if Netscape brings this product to market (anyone been to those infamous presentations and Netscape's devworld?)

Bongo is the easiest way to create Castanet channels, so if you are really interested in using Castanet we advice everyone to use Bongo for their application's user interface or even the entire application.

I agree and am still leaning towards Bongo for that reason. Along that note, any idea on when real pricing numbers will be out for transmitters? I have a 30 person Intranet I may want the technology for and the $15,000 unlimitted use is kinda out there for us :)

Their is no need to convert or something. We always guarantee that .gui files can be loaded in new versions. Backward compatibility code is added everywhere, although we are not backward compatible with the alpha releases anymore. But the .gui file format has not changes, so that should be no problem!

As properties are added to .GUI files how is this possible? Object Databases use versioning, are you using something like this for class maintenance?

Why are you so concerned? Sure, Bongo needs a lot of improvements but we are working hard on that. Also, you should not forget that Bongo is a very young product and if you compare that with the state of it we think we have a pretty solid product.

I agree with everything that Bongo does today. I'm just a little worried that the combination of IFC serialization and Java Beans may result in having similar products supported in these $99 products (like SuperCede and Visual Cafe) that are more "standard" for GUI development. As of now the code-builder paradigm seems very transitory as companies are admitting they need a better way and Bongo is out there for them to see (not to mention NeXT :) I'd hate to invest that much into Bongo if it will diverge from what Netscape may very well be pushing itself. I have confidence in the people at Marimba to keep things going, although rumours are always scary :)

Bongo is the best tool for creating Castanet channels. It is not an IDE, it is meant for usage next to an IDE or any other way of creating applications. We think that Bongo results in the most powerful user interfaces for Java that are currently possible!

I'm hoping that JDK 1.1 Betas flow quickly after the 1.0 release of Bongo. I don't use the Bongo scripts (sorry) but I use it along with a simple text editor and the combination still kicks the tail out of any IDE out there. Course, that is what I'm used to. The ability to use JDK 1.1 with my existing (you say forever upgradable) .gui files is very enticing :)

Anyway, could you give some more details on your concerns about Bongo's markes status. I'm just curious...

Klaas, my market status concern have to do with the above. You have alliances with Netscape yet Netscape is pushing the IFC and tools that use it (they even mention by name SuperCede and are selling Visual Cafe right out of their doors.) As of right now Bongo kicks their butt, but we are living in VERY quick times and I could imagine a close second coming by that DOES use the IFC and that could spell trouble market wise for Bongo. That is of course just my opinion but it stands to reason on many points. The comments made about how Bongo was almost killed in the Javology interview don't raise confidence either, sorry to say. I finally must convince I am in a horrible mire over this whole thing right now and I must appoligize for that on a personal level.

Tim Triemstra ........
Alpha Star International Atlanta, GA USA

Date: Mon, 06 Jan 1997 13:27:40 -0800
To: (Don Hopkins)
From: Arthur van Hoff <>

Hi Don,

Although I am pretty biased I would like to make one or two comments.

We decided to build a very AWT friendly GUI toolkit. What this means is that there are as few gratuitous differences as possible. We did this for two reasons. One is that we don't want our developers to relearn what they know about the AWT, and secondly we are anticipating the integration of JDK 1.1 functionality sooner rather than later.

The IFC has made a huge mistake in reinventing classes like the Event, Graphics, and Color classes. This makes it extremely hard to integrate IFC components into existing AWT applications (and visa versa). We think this is a great advantage of Bongo.

We also focussed on mimicking the PC look&feel whenever possible. We've had very positive feedback on this feature. It seems to be what people want. If you want you can still create your own look and feel, but at least the default is familiar to most users.

I strongly believe that JavaBeans is the right way to go. It is big, and it is not a framework for building widgets, but at a slightly coarser granularity it solves the problem of integrating components from other vendors very effectively.

Over the next few months we are going to put effort into the following areas:

Have fun,

Arthur van Hoff

Marímba Inc., 445 Sherman Avenue, Palo Alto CA 94306
415-328 JAVA (main), 415-328 5283 (direct), 415-328 5295 (fax),