[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] [prov] wondering how pluggable the IU user model is


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