Ole Arndt wrote:
Hello infant HiveMind community,This is correct.
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.
I think that will depend on the needs of the community, but Howard is the best person to answer that.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?
There you go..!!
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>
I actually like this as it is more intuitive even if it is visually confusing initially. You soon get used to it!
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
