[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 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