commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject [HiveMind] hivemind and avalon, revisited
Date Sat, 13 Sep 2003 14:20:49 GMT
Henri Yandell wrote:
>>So how is Hivemind different to Avalon?

Here we go again :D. I'll join in here to help get a sensible answer.
Lets see if we can document it somewhere this time....
(same content as this e-mail posted to the wiki)'s a more involved question than it seems...

The problem domain for HiveMind and "core" Avalon is nearly the same;
the general role of HiveMind in any application will be fairly similar
to that of something like Avalon-Fortress or Avalon-Excalibur: providing
configuration management, dependency setup, component instantiation, etc

= Design differences =

Avalon takes that problem domain, then adds a strong "containment"
concept (Avalon-Phoenix / Avalon-Merlin) in places, which comes with
additional security, various kinds of "standalone" features, and
corresponding extra setup.

What avalon also adds everywhere is a strong emphasis on several
patterns, like Inversion of Control, and a very rigid lifecycle (rules
that boil down to "set up logging then dependencies then create worker
threads" that are encoded in interfaces and enforced by containers) on
every component. All this makes avalon rather heavy to apply a system.
That's a disadvantage (lot of work, very much nonoptional dependency,
some flexibility lost) and an advantage (rigid, clean, structured,
common setup).


HiveMind simply makes a few different choices, with its own set of
advantages and disadvantages. There's no IoC, and various bits are /way/
more dynamic than is desireable in an IoC environment. Looking past all
the "features" and "history" of both frameworks, this, IMO, is the
actual big difference.

Which answers the implicit question "So why not combine HiveMind and
Avalon into a single project?": there are a few core design choices that
are different between HiveMind and Avalon that make the two distinctly


I might summarize that as "Avalon is a very rigid kind of component
framework, HiveMind acts a lot more like component 'glue'".

= Concrete differences =

For component writers and application assemblers (people who take a set 
of components and wire them together to make them actually "do" 
something), the differences are actually rather small. To
show how small, I wrote

which shows you how your component can be portable across avalon, pico,
spring, webwork/xwork, and I've now added HiveMind as well. Probably not 
too accurate, though.

= Other frameworks =

Howard M. Lewis Ship wrote:
> So there's definiately some overlap with Avalon.  If I didn't have my day job, and the
> work on "Tapestry in Action", I'd love to survey all the current microkernels, including
> Spring, Pico and so forth. 

I'm trying to maintain a wiki page to that effect:

but its been difficult for me placing HiveMind in any kind of "box", 
especially as its moving rather fast.

hope this helps,


- Leo

View raw message