[izpack-devel] [RFC] Proposal for a web-server based installation model

Rahul Bhargava me at rahulbhargava.org
Fri Mar 9 06:43:21 CET 2007


Hi -

I wanted to share some ideas on extensions to the current IZPack 
installation
model.

_*1.Web Browser-Driven Installer

*_Lot of applications today are created and deployed on a backend 
web-servers. In many
companies/projects, the web-server may be running on a blade server in a 
production data-center.
Running a standalone Java GUI in such a situation is many a times not 
feasible. Plus
the allure of using a web browser to do remote installs sounds very useful.

That brings me to the 'web-driven installer' framework proposal. The 
idea here is to
have a set of install descriptors  that drives a web-app (JSP/Servlet) 
using a browser
instead of a standalone Java GUI. The actual install actions will be 
triggered and
executed on the backend Java web-app container. But the beauty would be the
install could be done remotely from any web-browser. An embedded 
light-weight
Java web container like Jetty could be packaged to create standalone remote
install server or could be deployed into an existing Java web-container.

I looked at all the installer frameworks out there (InstallShield, etc) 
but could not
find what I described above.

I do see products like Joomla CMS, PHPbb etc create custom web-browser 
driven
installer so I though it would be mighty useful to have an open source 
based framework
for creating such installers.

I build server based products and I know I would love to use such a model.

I have not looked at the IzPack architecture in-depth to be able to say if
the existing codebase could be adapted for the above model. If this is
interesting to this project me and couple of other developers/friends  
would be interested
in collaborating.

_*2. Downloading, Compiling phases during Install

*_The other functionality I can see being very useful to my projects 
would be to
have descriptor driven actions for downloading native src files, trigger 
shell scripts \
to do the "configure, make, make install" cycle just-in time for the 
specific platform
and then continue with the install dialog.

Motivation here is a lot of times the binary incompatibilities between 
DLLs can be
escaped if the C/C++ code can be compiled on the machine directly. This 
would
require being able to check for appropriate versions of make, gcc etc. 
That could
be delegated to automake.

Looking for your comments.

-- 
Rahul Bhargava
http://www.rahulbhargava.org
Phone: (925) 265-8801(W)|895-2201(M)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/izpack-devel/attachments/20070308/9363c580/attachment.html 


More information about the izpack-devel mailing list