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

[Pat McCarthy <patmc@xxxxxxxxxx>]

Good scenarios maybe - but I'll have
to think through some again to see how often they might actually occur
in the tool/product specific world I have in mind.  I've often been
reminded that possible scenarios are not always practical scenarios (while
technically possible, you don't normally prepare for a sand-storm when
you go snow skiing :-).

Re your comments:

Your response to scenario 2)
>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.

Your response to scenario 3)
>Do Q1 and Q2 have different placeholder features?
If yes, then there is an issue. 

For both of these I'll have to consider
not how often do we see extensions that target multiple tool/product configurations
(there are some), but how often a user/customer actually has multiple tool/product
configurations that need the same extension.  Maybe this is a limited
scenario where either duplication of install or user managed replication
of the install is appropriate (or the extension supplier offers alternatives
for this or chooses to use a formal install routine on their own).

Your response to scenario 4)
>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) 

At this point maybe we have crossed
over into a domain where the user is conceptually aware of the way Update
Manager works to combine features from multiple sites so maybe it is not
that much of a hack. It is not like we are asking them to update the platform.xml
by hand, and if the prereqs for the extra features in the one install site
are not met then the feature should just be disabled anyway.

Re the Install wizard page UI thought:
>That will work, but it doesn't look very user
friendly, and may be confusing to users. 
I guess I'd have to see it/try it before
I could agree.  What I think usually happens is that people just click
next/finish until it starts downloading/installing - not looking or caring
much where the new code goes.  If the install location defaults to
a valid location that is not the product's own location - it might still
work the same for the "rapid click until it starts" user.  The
default location might look a bit like Mel's description.


Re your request for more detail on this
from me:
> 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).

Maybe private/public were bad
terms to choose.  Private in the thought above means "only to
a new/empty site".  Public means "any site that may already
exist or a new one if you want".
Goal was somehow get the Update Manager
UI to either force the user to choose a new site (or use a new site location
based on some default) or at least prevent the user from choosing an existing
site at the target because the feature says - no, I need to be alone(private).
 This would have to be overruled by a colocation-affinity statement;
the two together would mean put me with this colocation-affinity identified
feature or put me in a new install site.   Maybe better terms would
be install-stite=default|unique|any ?

I've got to think through this again
after another read of Mel's description of their desire and private implementation.

Maybe there is a short term (3.0) approach
that tools/products can define based on the current implementation and
then a more robust implementation (3.x) that accounts for a generalized
set of requirements that support Mel's scenario as well.

Pat McCarthy