Re: [equinox-dev] [prov] wondering how pluggable the IU user model is

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

I think I am more confused now.  On
the one hand it seems that the name of the entry point is "picked
at install time by the user"
but later you say "entry points are just IUs with a special tag that
the UI decides to show by default".  And further contradictory
"As for the name of entry point itself, I was not proposing this to
be a name shown to the user."  These all seem to be at odds with
each other.   My understanding was that the user defined the entry
point name and the name was used in the context of the current and future
provisioning operations.

So, who defines and names the entry
point IU?  When?  How is its visibitilty controlled?

Jeff

Pascal Rapicault/Ottawa/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx

08/22/2007 10:14 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] [prov] wondering how pluggable the IU user model is

The overall name would be picked at install time by
the user. By default
the name is the name of the IU you are installing. In most cases users
don't have to enter anything. To me there is no burden, you click on the
thing to install, a dialog says "are you sure you want to install?
what
name do you want to give it where a default is provided, (and a check box
to say don't ask me this question)". you click ok et voila.
If we don't have an entry point in a form or another (something tagging
what the user explicitly installed) then there is no way to clearly present
to the user what is installed. For example, today when you install the
SDK
you see all the groups, I don't find that clear. If we had entry points
only "sdk" would be presented.

> Just imagine the bug reports.  "When I go to add Mylyn it
says that the
Foo, Bar and Fred entry points need to be updated.  why?"
  I would personally prefer this kind of message over "the RCP
group needs
to be changed", especially when the user never heard about such a
thing.
  One thing that may not have been clear is that entry points are
just IUs
with a special tag that the UI decides to show by default. If the user
decides to move into super advanced mode, then all IUs in the profile could
be shown. As you said earlier, it then comes down to managing filters.

>From a technical point of view, entry points also allow us to store
the
degree of flexibility associated with it. For example the "c tooling"
entry
point could be setup such that move to a new version is always done
silently.

As for the name of entry point itself, I was not proposing this to be a
name shown to the user.


equinox-dev-bounces@xxxxxxxxxxx wrote on 08/22/2007 09:50:57 AM:

>
> I see.
> >- A user installs both CDT and DSDP at the same time and sees
this set
as
> >"C tooling". An entry points named "C tooling"
is created.
>
> Who picked the name "C tooling" (and when)?  if the
user in this
> scenario originally picked CDT and DSDP then they must have picked
> the overall name.    feels like "entry point"
has too many possible
> semantics associated with it (witness my interpretation of the
> term).  this also feels like a pretty high burden to put on the
> user.  Just imagine the bug reports.  "When I go to
add Mylyn it
> says that the Foo, Bar and Fred entry points need to be updated.  why?"
>
> This level of capability would be great for advanced users but for
> beginners it seems too demanding.  They just want to be told
what
> the interesting "groupings/entry points" are.  Since
this is how
> people interact with the provisining system, there needs to be some
> shared understanding of names etc.  If my Foo is different from
your
> Foo, we can't talk about it.  Perhaps this fits into the "bookmarks/
> favorites" metaphor mentioned earlier.
>
> Jeff
>
>

>
> Pascal Rapicault/Ottawa/IBM@IBMCA
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 08/22/2007 08:32 AM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> To
>
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> cc
>
> Subject
>
> Re: [equinox-dev] [prov] wondering how pluggable the IU user model
is
>
>
>
>
> It seems that there is some confusion around the concept of "entry
point".
> An "entry point" captures what the user installed in a profile.
These
entry
> points are what users  will remember they have installed. In
a UI for
> beginners, it will be what is being presented when the profile is
being
> browsed, thus allowing to hide group IUs, configuration IUs, etc.
> Entry point will also be the entity that users ask for update and
> uninstallation.
>
> Example:
> - A user installs both CDT and DSDP at the same time and sees this
set as
> "C tooling". An entry points named "C tooling"
is created.
> - When he browses his profile, he sees "C tooling" and can
act on it. By
> default, the groups that have been installed are not shown.
> - Now the user trys to install "Mylyn" but this requires
a higher version
> of the RCP group than the one currently installed thus requiring a
new
> version of CDT. In this case the user will be prompted with "do
you want
to
> update 'C tooling'", because it is the only thing he knows about.
He does
> not want to hear about the RCP or Platform feature or what else.
>
> In short, entry points are not things to be found in metadata
repositories.
>
>
> equinox-dev-bounces@xxxxxxxxxxx wrote on 08/21/2007 08:46:08 PM:
>
> >
> > Maybe I'm really wondering how much the IU taxonomy will change
from
> > product to product.
> >
> > We've already discussed that the presentation to the user of
what a
> > repository is may differ from product to product.  Or at
least that
> > most end users (of the Eclipse SDK, RCP products) are unaware
of
> > metadata and artifact repositories as separate entities.  I
would
> > expect that many products would want to keep the concept of a
"site"
> > (maybe plug in their own terminology or icons), so we must have
API
> > to find the artifact repo from a metadata repo or colocate them.
> > (See discussion in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=200259).
>
> >
> > Same is true for profiles.  A user of most RCP products,
and even
> > many Eclipse SDK users, would likely not want to know that the
> > provisioning infrastructure supports multiple profiles.  Their
view
> > is likely of the "product install location" or something
like that,
> > and the fact that there exists a profile that drove this
> > configuration, the fact that bundles might be shared, etc...would
> behidden.
> >
> > So now I'm wondering if the same is true for IU's, at least those
> > that the user knows about.  We have the notion of IU's that
are
> > groups (which is how we filter the IU views in M1).  And
Pascal is
> > thinking about an "entry point" concept that would
define what the
> > "product view" of a bunch of installable units would
be.
> >
> > Should we assume a particular taxonomy for most/all RCP apps
and
> > build a UI that can be reused in this way?
> > Pascal, do you think the entry point concept is the way that
we
> > would expect many/most products to show the user what they have?
> >
> > I used to think that I could build a fairly reusable update UI
that
> > could be plugged into different products.   Products could
define
> > their terminology for things like IU's (feature, add-on, plug-in),
> > and repositories (sites, repositories, etc.).  Then I realized
that
> > we need to do some mapping from the user view (site) to the reality
> > (metadata + artifact repo), and that we might have a default
> > strategy (such as colocation of repos), but ultimately we can't
> > assume how repos are presented to the user.
> >
> > Do we think that, for IU's, we can also come up with a default
> > strategy (such as entry points) for deciding how to present IU's?
> > ie, how to filter the list of IU's the user sees, and more
> > interesting, what would show up on the property page for those
kindsof
> IU's.
> >
> > I hope this makes sense....
> >
> > susan_______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev