shibboleth-dev - Re: More defined custom extensions mechanism
Subject: Shibboleth Developers
List archive
- From: Tom Scavo <>
- To: Walter Hoehn <>
- Cc: Chad La Joie <>,
- Subject: Re: More defined custom extensions mechanism
- Date: Mon, 11 Jul 2005 09:27:46 -0400
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YTO8a1tOMFWCHPqVoTbGWREb6GfvYdkPN9s+lP9YocN99L28Vcl601gQLD/qu59m4XZl9lyhfJ4Kptt+DzIdld4CE9PmEDDB3aoaa8I9t1/zdS1kWjvfa+LOiNeB/ocO+xKmYR+vNrYB5JwtUO2XEQ3z+ZDQvdAZqnpBLEMgvJY=
On 7/9/05, Walter Hoehn
<>
wrote:
>
> On Jul 9, 2005, at 4:26 PM, Tom Scavo wrote:
>
> > - protect ${idp.home}
>
> I added an extra warning here that requires that one explicitly hit
> "y" twice.
But that assumes that the user knows what phrases like "the existing
configuration" and "your Shibboleth IdP configuration" mean. Even
writing out the affected directory path (as the build file does now)
is not sufficient since the user may have no idea what files are in
that directory.
Part of the problem is simple terminology (consistent terminology
prevents user errors). As it stands, ${idp.home} is not really a
"home directory", it's an "install directory". A program "install
directory" can be uninstalled and is therefore volatile, whereas a
user "home directory" survives an uninstall. This is common practice.
For example, you can uninstall a browser or a PIM, but any existing
data files remain behind.
So I would expect to 'install' or 'uninstall' Shibboleth. I should
not be allowed to 'install' over an existing installation, although a
'clean-install' alias might be provided. Not even a 'clean-install'
should delete user files in a "home directory", however.
Tom
- Re: More defined custom extensions mechanism, (continued)
- Re: More defined custom extensions mechanism, Ian Young, 07/11/2005
- RE: More defined custom extensions mechanism, Scott Cantor, 07/11/2005
- Re: More defined custom extensions mechanism, Ian Young, 07/11/2005
- RE: More defined custom extensions mechanism, Scott Cantor, 07/11/2005
- Re: More defined custom extensions mechanism, Brent Putman, 07/08/2005
- Re: More defined custom extensions mechanism, Chad La Joie, 07/08/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/09/2005
- Re: More defined custom extensions mechanism, Walter Hoehn, 07/09/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/11/2005
- Re: More defined custom extensions mechanism, Walter Hoehn, 07/09/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/09/2005
- Re: More defined custom extensions mechanism, Chad La Joie, 07/08/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/11/2005
- Re: More defined custom extensions mechanism, Chad La Joie, 07/11/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/11/2005
- Re: More defined custom extensions mechanism, Chad La Joie, 07/11/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/11/2005
- Re: More defined custom extensions mechanism, Walter Hoehn, 07/11/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/11/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/11/2005
- Re: More defined custom extensions mechanism, Chad La Joie, 07/11/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/11/2005
- Re: More defined custom extensions mechanism, Chad La Joie, 07/11/2005
Archive powered by MHonArc 2.6.16.