hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Viktor Szathmary <phrak...@gmail.com>
Subject Re: hivemind impressions/comments/rant
Date Wed, 11 May 2005 04:23:22 GMT
hi,

thanks for all the comments :) i guess the discussion should be moved
to hivemind-dev, but hey, the developers read this anyway, and users
probably don't mind either..

On 5/10/05, Knut Wannheden <knut.wannheden@gmail.com> wrote:
> 
> On 5/10/05, Viktor Szathmary <phraktle@gmail.com> wrote:
> >
> > 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
> 
> My first impression of HiveMind was also that this dichotomy of
> services and configurations was sort of arbitrary. After all they are
> in the end both mapped to POJOs... But after using HiveMind for a
> while I got to appreciate this distinction. I define configurations
> whenever I need to provide an extension point with which other modules
> can affect the behaviour of "my" services.

based on the other comments i feel the service/configuration dichotomy
is a general point of confusion (and there's also the
parameters-schema deal which i also have some trouble placing)... i
think these concepts must be unified - it would probably simplify the
hivemind core implementation, as well as make things straightforward
for users.

don't make users run around in circular thoughts along the lines: "oh,
ok should a DataSource be service, or is it a configuration? sounds
like a config, after all it's just a jndi name based lookup, there's
usually one, no biz logic, etc.. but it doesn't make sense for my
service to depend on more than one... so it's a service... but it's a
configuration option of the app... aaaargh.. " :-)

> > I feel the XML configurations lack the simplicity and consistency
> > that's crucial for developers to effectively use the framework. What
> 
> IMHO the Hivemind "module descriptor language" is very well conceived
> in that the descriptors are very concise and crisp. Yet I agree with

it is true there are worse dialects out there (i don't like the spring
notation for example), but my idea of "concise and crisp" is at least
"no more verbose than constructing the same object directly in java"
and more like "as compact as ruby/yaml"... see below for some example
config-chunk i have, perhaps there are ways to simplify.it...

> http://thread.gmane.org/gmane.comp.jakarta.hivemind.devel/1388).
> Please join in on this if you have any concrete (or vague) ideas /
> opinions on this topic.

i will try to gather some thoughts and make further posts along this line...

> > Registry initialization should be more flexible and support different
> > deployment scenarios that are not one jar/one hivemodule. A common
>
> Would it help if the META-INF/hivemodule.xml mechanism were
> supplemented with a system property defining a list of descriptor
> URIs? I would be hesitant to add another configuration file with its
> own syntax.

the sub-module syntax is close enough, though it only allows
classpath-based loading, which is not ideal for me. i wrote a
ResourceUtil class that allows this style of addressing by adding the
classpath:/foo/bar.xml notation (along with the usual url protocols).

> I'd also be interested in how your code initializes the registry.

i will send the code for dissection to hivemind-dev later.

> > Documentation needs to be more example-based (at the least give more
> 
> This is definitely something we need to improve upon. There are some

I strongly suggest copy-pasted hivemodule examples from real-world
apps (rather than artificial toy examples), with some additional brief
comments/explanatio. It's also easier to add some comments to
something that works, rather than coming up with some contrived
example... toy examples should be runnable starting points/demos, the
real-world examples would provide best practices.

For starters, here are some fragments from our app's hive-config, that
provide a pluggable caching interceptor on top of a service.. I'm
actually hoping that this is a bad example and someone will point out
that I have overcomplicated things and it could have been done in 5
lines... ;) Once discussed, we can post this on the wiki as well...

------ NOTE: lengthy example follows -------

Actually, the example got so long, that I will post it separately :)

  viktor

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


Mime
View raw message