hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: Designing with Hivemind best practices
Date Wed, 04 May 2005 00:40:50 GMT
I'm curious how you would propose "persisting" something if you don't use a
database or a file.

-----Original Message-----
From: Renat Zubairov [] 
Sent: Tuesday, May 03, 2005 11:36 AM
Subject: Re: Designing with Hivemind best practices

I found installer proposal very interesting, I think my application will
need this feature in the future. But the question is how HiveMind can
contribute to the UI interface of the web-site? Should it be only web
specific request based or GUI specific or both.
I see two possible scenarious - one is that installer service worked allone
with installer application and provide the rest of the services with the
configuration information. After installer service/app done its job it is
not called.
Second approach is to draw an interface border between installer service and
possible installer UI interfaces users can created, the only thing is
important then is common persistent storage (as was mentioned in another
post on this topic made by James Carman). But it shouldn't be a database or
file, the storage information module should be modularized inside one module
(standart configuration service? symbol source?). Is any standart persistent
storages are planned for HiveMind like in Eclipse for example?

On 03/05/05, Chris Conrad <> wrote: 

I'm hoping that maybe we can strike up a discussion on some design
best practices when working with Hivemind.  Unfortunately, I'm not
the one to do much talking, but I'd like to pose some questions that
might get the ball rolling. 

After reading through The Server Side article and the documentation
it's my understanding that Hivemind services should small and fine
grained.  Assuming that I've got that aspect correct, my question
would be, what is too small?  For example, in the article there is a 
RegistrationService, UserFactory and UserRepository.  If I was to
start a design from scratch the most logical design for me would be
to combine the RegistrationService and UserFactory into a single
UserService and then keep the UserRepository as is.  How do you guys 
decide when a service is fine grained enough, or in the alternative,
what is too fine grained?

My second thought topic involves application installation.  I'm going
to use a standard J2EE web application for examples sake.  From my 
experience, you'd first set up your container as necessary (database
connections, javamail sessions, etc.) and then deploy your war or
ear.  At that point, however, most applications still have a good
amount of application specific that still needs to be done.  For 
example, setting up default preferences, creating the first admin
user, etc.  In the past I've simply had all of that in the database
sql initialization scripts.  It seems to me, however, that Hivemind
presents some interesting opportunities to make this more user 
friendly.  For example, an InstallerService could have a contribution
point which takes Installer services.  These can provide (if we were
using Tapestry) a Tapestry component and label.  The InstallerService
can use a Wizard component which pages through the different
Installer component contributions.  The individual Installer
components could use ApplicationDefaults for the default values.
Then the Tapestry front end can check with the InstallerService to 
see if installation is complete.  If it isn't, it can redirect to the
wizard which allows the user to do the initial configuration.

Hopefully this isn't too off topic for the list, but I'm really
interested in what people think about these things. 


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

Best regards,
Renat Zubairov 

View raw message