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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best regards,
Renat Zubairov
