The Artima Developer Community
Sponsored Link

Weblogs Forum
The problem with installers….

6 replies on 1 page. Most recent reply: Sep 15, 2004 5:47 PM by Jai

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 6 replies on 1 page
Calum Shaw-Mackay

Posts: 58
Nickname: calum
Registered: Mar, 2004

The problem with installers…. (View in Weblogs)
Posted: Sep 13, 2004 5:32 PM
Reply to this message Reply
Summary
….is that they either try to do too much (but end up doing very little of what you actually want), or they’re so miniscule there isn't one.
Advertisement
If you take a look at the state of play in general installer products, you find they are the one last bastion of the ‘take care of everything so you just have to click it’ mentality that survives outside of Microsoft. I’m not saying that taking care of things in order to support the smooth installation of a product for your users is always a bad thing, just that sometimes it misses the mark.

The big problem with recent installer systems is that they were traditionally founded on Windows platforms, where nearly everything was a known factor – the registry, environment variables, etc, etc. So if you wanted to install a COM component, you used regsvr32 or whatever your chosen dose of binary hell happened to be at the time. And all though everybody eventually crosses the line and begins to despise the registry, whether you know it or not (Does Add/Remove programs, showing applications you uninstalled three months ago, sound familiar?), the point is that the registry was a known point of intersection between the end system and the product developers – Windows developers just know you have a registry. Spooky how they know that isn’t it? In fact the concept of the Registry was so great (the reality of registering 1000’s of components and DLL’s wasn’t so great, though) that Microsoft decided to use the concept again for the .NET GAC (Global Assembly Cache, in this context, kind of similar to the HKEY_CLASSES with versioning)

With Java, the general concepts and ideas used in installers have replicated from the Microsoft world. However, you can’t take anything for granted. The biggest being the operating system itself, and then there’s the file systems, etc, etc. Java has nothing like the GAC, sure we have the endorsed directories, but those are the sanctity of ‘things that do special stuff’ and are not to be messed with by us mere mortals. In fact, the classpath allows us to specify any jar or directory for use with our programs. Which is good because we can have different versions of the same library in different files or directories, and we only have to specify what we need; the difficulty comes from that we have to know what we need. And this brings me back to my point about installers.

Either we put all the stuff that our applications depend upon into the installer and let it do it’s thing, however we run the risk, especially in the open-source enabled, internet savvy world we live in today, that we make our installations bloated and that people will already have the files that we bundle anyway, or that the installation systems we use to build the installers don’t actually provide the low-level configuration we need; or we provide intricate step-by-step instructions about where to download files and how to change batch scripts that we think people can follow, but if they're not developers themselves, they nearly always get mixed up.

So either we make things too simple for people, but find we have to make compromises because of the installer architecture, or we think the user to be a programmer ‘like us’ and assume too much of them.

I’ve messed around with installers, and as much as I would really love to put nice little installation pages that allow me to nicely enforce my restrictive license scheme that I myself thought up, that only allows you to run my product if you happen to be called Zebedee and your trial will only work for the twenty days following St. Swithin’s day, (not the twenty nights following St. Swithin’s day, I hasten to add), I just don’t feel it’s really what end-users want.

To me there’s five degrees of separation between the developer and the end-user, and at each stage the developer knows less and less about the target platform, and some mechanism has to take the responsibility instead.

  • Build – The developer’s machine knows where everything is that the program needs, otherwise it wouldn’t compile, run and be tested properly. Your IDE will probably be running your code, or you will have batch or ant scripts, tailored to your particular environment.
  • Release – The developer uses a product like Ant, Maven or CVS to build a binary snapshot (jar) of the product bubble i.e. ignoring any outside libraries, abstracting away dependencies on outside files.
  • Package & Post – The installation medium is created. Often the release and package steps can be merged together, although here more thought is given to the end-user system, creating Windows EXEs, Executable Jars, etc. Generally, any ancillary files, such as configuration are added with the binary snapshot, and, possibly, bundling of JREs.
  • Installation – The end-user downloads the code, and installs it onto their machine. That’s it. Installation is about unpacking the product and getting it onto the machine.
  • Configuration – The final part of the release cycle, should be the software being configured to sit correctly within the end-users environment, and informing the user of any prerequisite libraries they may need in order for the software to complete it’s function properly.

You see, to me the problem with do-it-all installers is that configuration is not a part of installation. If we presume to make configuration part of installation, we over-simplify it and make too many assumptions, like bundling libraries in, and not allowing users to specify locations of libraries that, dare I say it, they wish to use with our products. Combining installation and configuration seeks to maintain control with the product developer, not the actual person installing it.

I would argue that the better of the two ways is the ‘Script Instruction’ route, where we inform users how to change the classpath etc, and the dependencies of our products, but the danger here, as I mentioned above is that we can assume too much of the person installing the code.

What is needed is not a program that leads the way for the user, not letting them make the important decisions that they actually want to make, but something that actually helps the end user get the product onto the system (installation) and, as a separate phase, guides them in configuring the product the way they want to, but also takes away the hassle of getting these other libraries and dependencies.

I’ve been working on something like this, and it has been a real eye-opener for me, as it’s been fun (flexed quite a bit with the swing API, and got a chance to look at HttpClient), and although I don’t think it not nearly easy enough to use yet, it can build an executable Jar installer in about three seconds, and allows you to set specific pre requisite locations and if the user discovers they need these libraries a couple of clicks will start an automatic download, and install (or copy) to a user-specified location, even handling multiple concurrent downloads, updating the classpath for the batch scripts automatically as each file is downloaded and unpacked. Of course, there’s a couple of other goodies in there – A Jini configuration editor, so if you’re installing a Jini service, you can specify things like your codebase, policy and JAAS files, and manage a set of Jini configuration files. Then, when you click on the ‘Generate’ button, it automatically merges all your .bat or .sh files, customises the classpath to fit your environment, and sets up your configuration files.

And all of this came out of one simple problem for Jini project installations, “Just how do I know where the end-user’s Jini installation directory is?”


Jai

Posts: 5
Nickname: jarulraj
Registered: Apr, 2004

Re: The problem with installers…. Posted: Sep 14, 2004 1:24 AM
Reply to this message Reply
The five degrees of separation mentioned was excellent. I beg to differ in that fact that some installations are made too simple; There might be instances where you assume certain things, so that the end user is not bothered much. In fact one of the products I worked on (back in 2000)single button installation was a marketing feature where I had to assume certain things to make it possible. IMO, the target user defines the level of assumptions for the install creator.

Calum Shaw-Mackay

Posts: 58
Nickname: calum
Registered: Mar, 2004

Re: The problem with installers…. Posted: Sep 14, 2004 7:23 AM
Reply to this message Reply
>There might be instances where you assume
> certain things, so that the end user is not bothered much.

I agree, there are instances, where you can make a number of assumptions and are then able to take the responsibility for knowing what to do away from the user. This is what the regsvr32 and GAC allow on Windows, but Java doesn't even have those central repositories, which is why I think that AIO installation for Java deployment is more difficult than Windows.


> In fact one of the products I worked on (back in
> 2000)single button installation was a marketing feature
> where I had to assume certain things to make it possible.
> IMO, the target user defines the level of assumptions for
> the install creator.

But in many cases, installer systems only define one type of end-user.

The problem comes that the more complex and larger the project, the more difficult it is to provide a slick all-in-one installation.

I mean perhaps the goal of all-in-one installation is a worthy one, but most of the current systems don't fulfil that dream.

Ravi Hegde

Posts: 1
Nickname: ravihegde
Registered: Oct, 2003

Re: The problem with installers…. Posted: Sep 15, 2004 4:28 AM
Reply to this message Reply
> In fact, the classpath
> allows us to specify any jar or directory for use with our
> programs. Which is good because we can have different
> versions of the same library in different files or
> directories, and we only have to specify what we need; the

Hmmm.... true only if I want my software to fail in strange ways later ! Why ? Because of inherent problems with this approach. My program is referring to ../blah/blah_1.2.jar. User uninstalls (read as deletes) blah application. Boom.... there goes my application along with it - sure to fail with "ClassNotFound" exception. Want more trouble ? User upgrades to blah_2.0.jar and new jar is not compatible with earlier jar. Again, Boom ... I am in trouble. Result : Increased cost of customer support on the least expensive side and losing customers on the more expensive side :(

> Either we put all the stuff that our applications depend
> upon into the installer and let it do it’s thing

Good choice. Anything else is inviting serious trouble later. Users curse my app, my installer and me. Again, same result ... increase customer support cost and/or lose your customers !

> a couple of clicks will start an
> automatic download, and install (or copy) to

Don't forget resuming partially downloaded stuff ... least painful way is the path to take :)

Mike Dunbar

Posts: 12
Nickname: mikedunbar
Registered: Jun, 2004

Re: The problem with installers…. Posted: Sep 15, 2004 11:14 AM
Reply to this message Reply
> > In fact, the classpath
> > allows us to specify any jar or directory for use with
> our
> > programs. Which is good because we can have different
> > versions of the same library in different files or
> > directories, and we only have to specify what we need;
> the
>
> Hmmm.... true only if I want my software to fail in
> strange ways later ! Why ? Because of inherent problems
> with this approach. My program is referring to
> ../blah/blah_1.2.jar. User uninstalls (read as
> deletes) blah application. Boom.... there goes my
> application along with it - sure to fail with
> "ClassNotFound" exception. Want more trouble ? User
> upgrades to blah_2.0.jar and new jar is not
> compatible with earlier jar. Again, Boom ... I am in
> trouble. Result : Increased cost of customer support on
> the least expensive side and losing customers on the more
> expensive side :(
>
> > Either we put all the stuff that our applications
> depend
> > upon into the installer and let it do it’s thing
>
> Good choice. Anything else is inviting serious trouble
> later. Users curse my app, my installer and me. Again,
> same result ... increase customer support cost and/or lose
> your customers !
>
> > a couple of clicks will start an
> > automatic download, and install (or copy) to
>
> Don't forget resuming partially downloaded stuff
> ... least painful way is the path to take :)

Think I agree with this post. If the users are savvy enough to be tweaking dependencies & classpaths, they can do it via a route other than the installer. They can just figure it out, or you could provide them instructions or another tool.

Seems better to keep the installation simple & fail-safe (because you've packed everything required ), even at the cost of flexibility.

Calum Shaw-Mackay

Posts: 58
Nickname: calum
Registered: Mar, 2004

Re: The problem with installers…. Posted: Sep 15, 2004 2:27 PM
Reply to this message Reply
> > Either we put all the stuff that our applications
> depend
> > upon into the installer and let it do it’s thing
>
> Good choice. Anything else is inviting serious trouble
> later. Users curse my app, my installer and me. Again,
> same result ... increase customer support cost and/or lose
> your customers !


I agree in some ways, if some or all of these are true
a) You have unlimited bandwidth and diskspace on your servers and thus large singular downloads are not a problem
b) You are producing a commercial product and thus can create CD's etc of your product
c) You have redistribution rights/license to any software your product uses, and can thus package it

But I don't believe, especially in the arena of open source, that this is always the case.

My point is if only a single file in your product changes between upgrades and your product is 2MB in a package of 20MB, do your users really want to download another 20MB

> > a couple of clicks will start an
> > automatic download, and install (or copy) to
>
> Don't forget resuming partially downloaded stuff
> ... least painful way is the path to take :)

Yes. Thanks for that - I'll have to add it in.

Jai

Posts: 5
Nickname: jarulraj
Registered: Apr, 2004

Re: The problem with installers…. Posted: Sep 15, 2004 5:47 PM
Reply to this message Reply
Have you tried rebol ? Not been there recently but its worth a look or even more! http://www.rebol.com

Flat View: This topic has 6 replies on 1 page
Topic: Design for Usability Previous Topic   Next Topic Topic: Tip: Enabling personal knowledge management


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us