commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Lear <r...@zopyra.com>
Subject RE: [HiveMind] Forming the community
Date Mon, 15 Sep 2003 14:49:09 GMT
On Monday, September 15, 2003 at 10:22:08 (-0400) Howard M. Lewis Ship writes:
>...
>I think its about managing dependencies.  HiveMind has limited
>dependencies on some other commons projects and on Javassist.  If you
>build some HiveMind glue to another project, you may inadventantly
>require the other project as a dependency, so you add a few KB of
>HiveMinde glue and, possibly, many megs of external dependency.
>...
>So, I'd rather have a new module, say "hivemind.standard.hibernate"
>that contains wrappers around Hibernate than have those wrappers part
>of the main library whether you use Hibernate or not.
>...

Good points, I agree.

>Sounds like a decent idea for me; we're doing something similar at
>WebCT shortly and I'm pushing to leverage HiveMind. Now if only I
>could MANDATE it ...

You've been reading Nietzsche again, haven't you!

I've just successfully built and run the example you provide in the
documentation.  This is a good start.  I do think that the example in
particular, and HiveMind in general, would be helped by a discussion
of the advantages of declarative programming and how it can be used to
simplify testing of applications.  I liken this to Laplace transforms,
with which one transforms work to be performed from one domain that is
difficult, into another which is easier.  A mention of why certain
parts of the application are transformed (construction of services),
and not others, would also be helpful to guide developers in their
choices.

Extending this, one needs to show exactly how programming for testing
(PFT) becomes possible or at least much easier.  Without such a
concrete demonstration of the ease of switching between production
and testing implementations, the plumbing looks to the untrained eye
to be just so much dressing for no purpose.

So, I would suggest as we move forward that we realize our high-level
goals directly in the example.  So, the example should include
multiple independent HiveMind services ("independent" yoked to
HiveMind is of course redundant) and perhaps an application that uses
these services in production, and also, mock services (if that is the
appropriate term) that implement the services for testing purposes.

This brings another thing to mind: would it be appropriate/possible
for HiveMind services to also provide a mock version of their service?
Or is the particular implementation of mock services too much dependent
upon the application in which they are used?


Bill

Mime
View raw message