Re: [platform-update-dev] Update Manager Installs - Forcing the Use of a

[Dorian Birsan <birsan@xxxxxxxxxx>]

Thanks Pat, that's a good set of scenarios.
A while ago, Mel M. and I have exchanged
some email on a related topic and one of the concerns I had with features
deciding where they can be installed was the potential for security loopholes.
That's why the colocation-affinity with a feature seemed to me a better
(temporary) solution.
See some comments below:

platform-update-dev-admin@xxxxxxxxxxx wrote on 04/20/2004
05:40:43 PM:

> 
> Well - that could work - a use what you have approach. 

At least for the remaining of the 3.0 release it would
be nice to avoid introducing more concepts.

> 
> That would mean that all additional software is lumped in one place
> - and that itself might cause problems. 

Yes, but it will all be under the control of the product,
as opposed to the feature being installed.

> 
> Assume Product Q and extensions R and S (now that there is no 
> difference between an Update Site and an Extension Site. 
> 
> So if I read you right: 
> 
> d:\q_inst_dir\ 
>         \eclipse  (<- Product inst dir,
which itself may have other 
> extension sites) 
>                 \features
>                 \plugins 
>         \other\... 
>         \extension_home (<-target for extension
installs) 
>                 \features
>                    
    \q.placeholder.feature 
>                 \plugins 
>                    
    \q.placeholder.plugin 
> 
> 
> R and S would say that they have colocation-affinity with q.
> placeholder.feature. 

yes

> 
> But, lets consider a couple of scenarios: 
> 1) When R or S needs to install lots of other stuff to support their
> tool (sometimes the feature/plugin portion is just a small bit of
> what is required), they would not want to hide it in the 
> \extension_home area so it would be installed somewhere else. At 
> this point they would probably have a formal installer for the 
> extension, so we can say they don't use this placeholder technique.


sounds good.

> 
> 2) If the user has multiple Eclipse-based products installed (Q1,
> Q2), they may find that R or S was able to extend multiple targets.
> What to do then?  Download into one \extension_home dir and then
> download again for the next product? (but again, maybe we say they
> don't use this placeholder technique). 

The install is triggered from one of the products,
so the extension is installed in the location associated with that product
(say Q1).
Now, the collocation affinity should be a hint, and
the user can install it in a common product extension site that is shared
by Q1 and Q2.

> 
> 3) Same as 2), but from the extension's viewpoint - which 
> placeholder.feature to they identify in their feature to be 
> installed? Q1 or Q2? (Or do they avoid the issue by deciding not to
> use the placeholder technique). 

Do Q1 and Q2 have different placeholder features?
If yes, then there is an issue. 

> 
> 4) Say I download and config both R and S using Q1.placeholder.
> feature. But I also need R over in Q2.  I can't use the Software
> Updates > Manage Configuration dialog to do this by adding 
> \extension_home as a linked site as I'd get both R and S and then
> need to go disable one of them, but the R feature could not target
> both Q1 and Q2. 

You're right.
The support exists in platform.xml, because it can
define what site and what features/plugins from the site to pick up, but
this is not exposed in the UI yet.
Perhaps you can add it, and then open the configuration
manager to disable features you don't need (looks like a hack)

> 
> These problems might cause a bit of trouble.  There still might
be 
> room for products to create this structure to support their own 
> after-the-install add-ons, or if they want to organize their own 
> code into \extension_home, or just offer this as a target for 
> feature/plug-in sets that only plan on extending the one tool. 
> 
> Guess I'd still like to understand what it would take in feature.xml
> to get the Update Manager installer, when loading from an update 
> site, to choose a default location other than the product's install
tree. 
> We could add some attribute to the feature spec that says install
in
> location XYZ, where the file system location of XYZ is platform 
> specific (C:\Program Files\XYZ on Windows for example).  This
would 
> have to be either supported when only defined for a root feature 
> (included features follow parent) or it would have to be defined in
> every feature (a pain). 

Yes, something along these line is needed.

> 
> Or maybe the solution is do very little - just change the default.
 
> Assuming we'd not prevent the user from changing the target 
> directory, we can't stop them from putting it in the 'wrong' place.
> Maybe all we really need is a target site on the Install wizard page
> that chooses a new target site based on the feature id and some 
> default location that is not the current product's Eclipse dir.  We
> could use a wizard page that includes a new toggle that is selected
> by default. The toggle would say "Create new target install site"
- 
> where the location is based on a platform default.  Changing
the 
> default target location to another location should be possible while
> the toggle is selected, but if the toggle is not selected then all
> they do is choose an existing install site. This reverses the 
> current flow where an existing site is selected by default.

That will work, but it doesn't look very user friendly,
and may be confusing to users.
 
> 
> Or - a less specific statement in the feature.xml might just say 
> install-site="public|private" - public is a rule for any
site will 
> do (new or existing) while private is a rule that says a new or 
> empty install site must be used (Default public).  If this could
be 
> said once for a feature and applied to any included feature.... it
> might work too. 
> 
> Of course all of this may be more than what some want or think they
> need. If you want to cram all your plug-ins into one site I guess
> you should be allowed.  I'm trying to consider the case for how
to 
> best manage a common base that is provided by one vendor but 
> extended by others (formal ISVs and other feature/plugin sets that
> might be discovered by the customer).  In this scenario we don't
> want the additional code to get deleted when the existing product
> install is reworked (an uninstall/reinstall form of update for example).


Can you describe this scenario in a bit more detail?

> 
> 
> 
> Pat McCarthy

-dorian