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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

These questions make a lot of sense
and you are hitting on one of the key challenges.  Some thoughts....

- First, we do not *have* to solve all
these problems.  In fact, we likely should not try to in the first
few cuts.  The world will crumble under the weight of what might be.
 Rather, we should try to incrementally extend the solution to include
more flexibility.  Ultimate power will come to those willing to rewrite
the UI using the building blocks that you supply.

- Entry points (other call them "offerings",
"products", ...) are a useful and generic notion.  But (there
had to be one), one person's entry point is another's internal implementation
detail. So the interesting question becomes, how does the user see only
the "entry points" that they should see?  who is controling
that experience?  If you as a producer of an IU mark it as an entry
point, that may not fit with view of the sysadmin/system integrator at
company/site/... X.  Do they rewrite the metadata?  Somehow override
it?  Provide another repo and somehow hide the one you supplied?

- Feels like alot of this comes down
to filtering and filter definition/management.  For example, perhaps
"entry points" are just a query/filter.  You can have yours
and I can have mine.  Product / company X may have some too.  Sort
of like a set of bookmarks.  Here are the cool things you can install
from the known galaxy of IUs.  I can mail you my queries, post them
on a website, blog, CVS, ...

- certainly colocation of the repos
will be a common case.  We of course are planning for the uncommon
and fully supporting separate locations. It would be a bummer if having
separate locations was somehow an advanced option.

- One ofthe thoughts we have had in
the past was that repo locations could be something that is added/installed
into the agent itself.  So, for example, the agent can get updated
with more/different repo locations just as it might get updated code.  Somehow
knowing about one (say a metadata site) got you a mess of info about others
(and so on).

- Changing the wording from product
to product is cool but I'm not sure it is key.  Perhaps having a range
of metaphors or workflow complexities is more apt here.  Sort of like
identifying the 3 or 4 users that we talked about before and supporting
them in a first class way.  From there we can look at pluggable messaging
etc.

Jeff

Susan M Franklin <susan_franklin@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

08/21/2007 08:46 PM

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

To	equinox-dev@xxxxxxxxxxx
cc
Subject	[equinox-dev] [prov] wondering how pluggable the IU user model is

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 be hidden.  

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 kinds of IU's.  

I hope this makes sense.... 

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