commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <>
Subject Re: [HiveMind] Registry
Date Wed, 17 Sep 2003 16:35:07 GMT

Ole Arndt wrote:

>Hello infant HiveMind community,
>first a short self-introduction: I am a developer from Germany. For
>my pet project, a mud like simulation, inhabited by (more or less) intelligent
>agents, I was looking for a framework to use. I knew Avalon from my
>job and had heard of pico- and swing container. When I discovered
>HiveMind I was equally impressed by the underlying concepts, the
>amount of documentation and the clean code. 
>Until now I haven't build anything with HiveMind but I have compiled
>it, ran the tests and did some source code reading.  I lurked on the
>devel list (via gmane) for a few days to learn about the people and
>the current status of the project. But now it's time to step forward
>with a few questions/remarks. Here we go:
>The HiveMind registry is currently static, right?  Once constructed it
>can't be changed. 
This is correct.

>Due to the potentially very long run times of my
>simulation I want to be able to add/remove modules/services on the fly
>at any time. If get it right, this is currently only possible by
>building an new registry. Correct?
>What I want to have in the end is some kind of new service
>notification mechanism like in the beancontext API, or with a Jini
>lookup service. This does not need to be build into HiveMind, but is
>probably only possible/easier with some support from the lower level.
>Any plans in this direction or is this out-of-scope for HiveMind?
I think that will depend on the needs of the community, but Howard is 
the best person to answer that.

>An easy improvement in this direction would be if the RegistryBuilder
>took an old Registry to build upon as a parameter. This would probably
>imply that the registry keeps its XML configuration.
>Regarding the XML configuration: I agree that the current naming
>really isn't very intuitive. I think the best proposal until now is
>the one Harish made:
><service> --> <service-point>
><extend-service> --> <service>
><extension-point> --> <configuration-point>
><extension> --> <configuration>
There you go..!!

>Though, if some native English speaker found a more descriptive word for
>`point', like `definition' but not as long, it would be even better :-)
>Another issue: There isn't much visual difference between the
>following two lines and that makes it hard to read:
><extension-point id="" />
><extension point-id="" />
>What speaks against calling the id attribute `id' in both cases?
I actually like this as it is more intuitive even if it is visually 
confusing initially. You soon get used to it!


View raw message