hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <>
Subject Re: hivemind impressions/comments/rant
Date Tue, 10 May 2005 07:34:57 GMT
Hash: SHA1

Viktor -

~  I'd like to thank you for your comments - none of which I viewed as
anything close to a rant. Yours are the types of comments I like to see
in that you name points and express your views directly. What caught my
eye initially - and it must be saying something because it's left to
your second to the last paragraph - was the documentation. I,
personally, hate writing it - but have come to appreciate its
importance. Just yesterday I informally started my solicitation for "any
user-based examples/documentation" in order to address that very
problem. [note to users/developers - this is a semi-formal request - if
you've got anything that can be used as a basis for any kind of
_user-based_ 'how-to', documentation, examples - feel free to contact me
off-list so I can get more put together to address this issue (<rant>and
don't say "Wiki" - they're good, but shouldn't be a replacement for good
online user documentation </rant>)]. In comparing Hivemind's site
documentation to other projects', there seems to be a lack of
'start-to-finish' getting started help. I'd like to alleviate that with
any assistance available.

~  To address your 'headaches' - I have no real views either way as to
Hivemind's syntax. To say it "reinvents" might be pushing the envelope a
little. Does it have its own? Most definitely. But which "pre-existing"
wheel would one choose otherwise? To a point I suppose you could say "I
want to use X so let me use X", but there would more than likely have to
be a) a configuration for that as well and b) some sort of mapping
between 'X' and Hivemind internally for the configuration to be
meaningful. Would it be ideal to have "1" way of writing XML
configurations across the the multitude of projects that use XML
configurations? Absolutely. 1 for Spring, Hibernate, Hivemind. Life
would be truly "good". But that isn't a reality. I believe that
addressing Hivemind configurations specifically - they are relatively
short and more meaningful than they were in the past. A clear
'lifecycle' would make the API easier to use, but that takes me back to

~ (You've got me on service vs. contribution - I use what works :-( )

~  As to your point about one jar/one hivemodule - I believe this would
be best provided as a component in and of itself. Maybe I read that
wrong, but to include it in Hivemind itself would require - yet more
configuration. [Granted - providing it as a service/contribution that
was 'off' unless configured would impose no greater configuration on a
user that didn't wish to utilize it, but then we get back to
documentation - let people know it's there and how to use it]

~  I have utilized Hivemind on a few projects of moderate size and
haven't felt the pain of 'tedious pages of XML' any more with Hivemind
than I have other projects that utilize XML configurations. I work on
component pieces - both in code and configuration. Not to say it's not
an issue, just not one I'm versed enough with to have a true opinion. It
wasn't until recently that I started stepping outside of my own sandbox
where I created all classes/interfaces and started to play in Sun's (my
foray into Hivemind w/ Swing) that I truly hit the
examples/documentation issues you raised. I believe that starting there
would be the best place to remedy most user problems. Not to say it
would make Hivemind perfect - just easier to see how to do what and when
- - thereby making it easier to make decisions as to whether it fits the
bill for a given task.

~  Thank you again for your comments.


Viktor Szathmary wrote:
| Hello,
| as a relatively new user of HiveMind, I thought I would share my
| impressions/thoughts after applying it on a medium sized project.
| Please take this as constructive criticsm. Some of the issues are just
| part of the learning curve, some of them are due to the fact that it's
| still in it's early stages, and some of them I feel are issues with
| general approach taken.
| HiveMind seems to be a mixture of an IoC/dependency management
| container and a a POJO/XML data binding framework, with a bit of
| xml-based scripting thrown in. No real issues with the IoC part - the
| concept is well estabilished and I find it natural to think in these
| terms. The headaches start with the OO/XML binding framework.
| For simple dependencies, it's easy enough to set things up. The first
| dubious point is the distinction between services and configurations.
| IMHO this distinction really doesn't help at all: it doesn't add any
| value to introduce two concepts, where one would be sufficient. Both
| services and configurations are objects that get initialized via xml
| declarations and have dependencies. It's not clear to me, at what
| point a certain dependency should be a service or a config. A
| configuration seems to be necessary when I want to create a reasonable
| XML syntax (schema) for initializing objects of this kind later on
| (and even though you can make the xml for configurations look
| reasonable, they remain Lists which is an artifact that impacts the
| domain object model).
| I feel the XML configurations lack the simplicity and consistency
| that's crucial for developers to effectively use the framework. What
| would have been a few simple lines of java code (not to mention a
| scripting language) become tedious pages of XML. I feel HiveMind
| reinvents the XML/OO binding wheel once again, estabilishes it's own
| schema language, variable substitutions etc. IMHO this is a critical
| issue. It would be better to promote the Java based dependency
| management APIs and expose them to direct manipulation, scripting
| languages and your favorite java/xml binding framework, rather than
| trying to reinvent this. Madness lies this way, and you can already
| see the numerous dead corpses on the roadside :) - think Jelly, the
| numerous wretched xml/oo mappers that would be best to forget, etc..
| Registry initialization should be more flexible and support different
| deployment scenarios that are not one jar/one hivemodule. A common
| real-world example is environment-specific configurations. The
| approach I implemented was a custom registry initialization sequence,
| that after addDefaultModuleDescriptorProvider(), finds a
| "hivemind.registry" in the classpath, and loads the further
| hivemodules listed there (these are simple resource URIs that look
| like classpath:/com/example/foo.xml or
| file:/foo/myproject/config.xml), then loads further config resources
| that were programmatically added (eg. from a testcase setUp()). I feel
| this should be part of the framework - if you're interested I can send
| the corresponding code.
| Documentation needs to be more example-based (at the least give more
| guidance on where in the reference to look for things). It's a real
| headscratcher to figure out some of the functionality that is clearly
| there (jndi, ejb remoting, etc). Guidelines/best practices should be
| focused on.
| Again, don't take the above as flamebait, but as a call for discussion
| and improvements :) I think for HiveMind to succeed, it needs to
| provide a very solid and simple core, and focus on it's essential
| strenghts.
| Best regards,
|  Viktor
| ---------------------------------------------------------------------
| To unsubscribe, e-mail:
| For additional commands, e-mail:
Version: GnuPG v1.2.5 (MingW32)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message