commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Arndt <...@sugarshark.com>
Subject [HiveMind] Registry
Date Tue, 16 Sep 2003 21:59:44 GMT
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. 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?
 
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>

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?

Ole
-- 
Ole Arndt                     http://www.sugarshark.com


Mime
View raw message