hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renat Zubairov <renat.zubai...@gmail.com>
Subject Re: Designing with Hivemind best practices
Date Tue, 03 May 2005 15:36:21 GMT
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 <cconrad@vasoftware.com> 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.
> 
> --Chris
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> 
> 


-- 
Best regards,
Renat Zubairov

Mime
View raw message