Installation UI?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Installation UI?

Jeremy Boynes
Aaron's installation questions got me thinking about the UI for the
installer and the challenge of doing the initial configuration. We don't
really want people editing plans (vi + an XML file does not seem
user-friendly to me) so how can we provide them an alternative.

How about if we added a UI component to the configuration bundle? So in
addition to the state file (config.ser) there was also a UI component
that the bundle could provide for editing its manageable persistent
attributes.

This would have the advantage of allowing each bundle to provide a
better UI than a set of name/value pairs, and would avoid hard coding
any particular UI code into the installer.

--
Jeremy

Reply | Threaded
Open this post in threaded view
|

RE: Installation UI?

Jeff Genender
 
>> vi + an XML file does not seem user-friendly to me

You need the XML plugin for VI...its awesome ;-)

Jeff

-----Original Message-----
From: Jeremy Boynes [mailto:[hidden email]]
Sent: Monday, May 16, 2005 8:41 PM
To: [hidden email]
Subject: Installation UI?

Aaron's installation questions got me thinking about the UI for the
installer and the challenge of doing the initial configuration. We don't
really want people editing plans (vi + an XML file does not seem
user-friendly to me) so how can we provide them an alternative.

How about if we added a UI component to the configuration bundle? So in
addition to the state file (config.ser) there was also a UI component that
the bundle could provide for editing its manageable persistent attributes.

This would have the advantage of allowing each bundle to provide a better UI
than a set of name/value pairs, and would avoid hard coding any particular
UI code into the installer.

--
Jeremy


Reply | Threaded
Open this post in threaded view
|

Re: Installation UI?

ammulder
In reply to this post by Jeremy Boynes
        I think we'd need to change some of our configurations for this to
work.  For example, we need some UI to decide between Jetty and Tomcat,
and I don't really want to offer two totally separate editors for the two
web containers and no way to enforce that one of the two must be available
and that the ports shouldn't conflict and all that.

        Generally it would be nice to have some multi-component-spanning
validation so you could, for example, ensure that *no* ports conflict -- I
guess that's not critical in the first release, and editors for each
configuration could be a good start.

        For installation, we'd have to either customize or replace IzPack.  
Do you have an alternative in mind?

        If we were going to offer this for installation purposes, we might
as well make it a general-purpose configuration UI that can be used
post-installation too.  Again, one of my priorities is the ability to
change configurations without starting the server.  So would the GUI edit
the configuration information in place?  I still have a strong preference
for XML as opposed to serialized stuff -- I expect this would mean we'd
want to define a startd XML format that all config stores would use (so
they'd store the same XML, regardless of whether they store it in a DB,
filesystem, etc. as opposed to each config store defining its own XML
format or something).

Aaron

On Mon, 16 May 2005, Jeremy Boynes wrote:

> Aaron's installation questions got me thinking about the UI for the
> installer and the challenge of doing the initial configuration. We don't
> really want people editing plans (vi + an XML file does not seem
> user-friendly to me) so how can we provide them an alternative.
>
> How about if we added a UI component to the configuration bundle? So in
> addition to the state file (config.ser) there was also a UI component
> that the bundle could provide for editing its manageable persistent
> attributes.
>
> This would have the advantage of allowing each bundle to provide a
> better UI than a set of name/value pairs, and would avoid hard coding
> any particular UI code into the installer.
Reply | Threaded
Open this post in threaded view
|

Re: Installation UI?

Jacek Laskowski-5
Aaron Mulder wrote:

> If we were going to offer this for installation purposes, we might
> as well make it a general-purpose configuration UI that can be used
> post-installation too.  Again, one of my priorities is the ability to
> change configurations without starting the server.  So would the GUI edit
> the configuration information in place?  I still have a strong preference
> for XML as opposed to serialized stuff -- I expect this would mean we'd
> want to define a startd XML format that all config stores would use (so
> they'd store the same XML, regardless of whether they store it in a DB,
> filesystem, etc. as opposed to each config store defining its own XML
> format or something).

It got me thinking about different serialization schemes. I don't know
how it works now, so it might already be available, but shouldn't we
abstract the serialization stuff and allow to plug in the one an
administrator wants? Currently, configuration is serializable, but does
it have to be? We could create a SPI (service provider interface) so
people could create their own implementation whereas the one that's
available now would serve as a reference.

> Aaron

Jacek

Reply | Threaded
Open this post in threaded view
|

Re: Installation UI?

Jeremy Boynes
In reply to this post by ammulder
Aaron Mulder wrote:
> I think we'd need to change some of our configurations for this to
> work.  For example, we need some UI to decide between Jetty and Tomcat,
> and I don't really want to offer two totally separate editors for the two
> web containers and no way to enforce that one of the two must be available
> and that the ports shouldn't conflict and all that.
>

I agree we need to change the configurations. Instead of two
mega-configs containing everything and the kitchen sink, they should be
more modular. However, doing this requires changes to the configuration
class loader which I've been holding off on until after certification.

> Generally it would be nice to have some multi-component-spanning
> validation so you could, for example, ensure that *no* ports conflict -- I
> guess that's not critical in the first release, and editors for each
> configuration could be a good start.
>

I'm not sure this is practical - you don't know which other ports are in
use, and even if you knew what Geronimo is using you don't know what
other ports are going to be used at runtime.

> For installation, we'd have to either customize or replace IzPack.  
> Do you have an alternative in mind?
>

No - we used InstallAnywhere for JOE but needed a license.

> If we were going to offer this for installation purposes, we might
> as well make it a general-purpose configuration UI that can be used
> post-installation too.  

I agree - it would be really cool if the UI components could be used in
a web console, in MC4J or anywhere. We used portlets for the components
in the console because they were pluggable and we could tweak the UI
easily in the aggregator. JSF may also be an alternative - any other
suggestions?

> Again, one of my priorities is the ability to
> change configurations without starting the server.  So would the GUI edit
> the configuration information in place?  

You don't need to start the server, just load the configuration to get
to the GBean attributes.

"Edit in place" - we don't do that now. AIUI each config store dumps the
data in its own place/way.

I actually that's a bug - there are some config store (e.g. the one that
loads from a Maven repo) that don't have a good place to dump the state
to. Also the local state is server specific. So instead of storing with
the configuration, we should have a central store for attribute overrides.

> I still have a strong preference
> for XML as opposed to serialized stuff -- I expect this would mean we'd
> want to define a startd XML format that all config stores would use (so
> they'd store the same XML, regardless of whether they store it in a DB,
> filesystem, etc. as opposed to each config store defining its own XML
> format or something).
>

How the central store would persist the overrides would be down to its
implementation. XML may a good format for this; alternatively we could
put it in a database (say a Derby instance) - that way we could also
make the updates transactional at some point.

--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: Installation UI?

Bruce Snyder
On 5/17/05, Jeremy Boynes <[hidden email]> wrote:

> >       Generally it would be nice to have some multi-component-spanning
> > validation so you could, for example, ensure that *no* ports conflict -- I
> > guess that's not critical in the first release, and editors for each
> > configuration could be a good start.
> >
>
> I'm not sure this is practical - you don't know which other ports are in
> use, and even if you knew what Geronimo is using you don't know what
> other ports are going to be used at runtime.
>
> >       For installation, we'd have to either customize or replace IzPack.
> > Do you have an alternative in mind?
> >
>
> No - we used InstallAnywhere for JOE but needed a license.

What about building our own installer/post install configurator using
the JGoodies (https://jgoodies.dev.java.net/) set of projects? It's a
BSD licensed project so there wouldn't be an issue including it with
Geronimo. Yes, this means that we would need to architect an
installer/configurator but the upside is that it would work for both
scenarios which is very important for us.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/