[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] [prov] p2 for starters
|
Answers embedded
equinox-dev-bounces@xxxxxxxxxxx wrote on 03/27/2008 04:59:37 AM:
> Hi @ll :)
> We (Wind River) are evaluating the technology, can you guys help me
> understand some basics?
> - What's the difference between groups and categories, when should each
> be used? Is it a pure UI thing?
Group, categories, etc are just markers indicating the kind of thing
you are looking at. It is mostly used by the UI. It is not used by the
core.
> - Is p2 allowing nested groups like these:
> - Repo
> -- Group A
> --- Group A.A
> -- Group B
At the core level the nesting is obtained by requiring other things.
This allows you to obtain arbitrary nesting. Also it is importnat to note
that p2 does not constraint you to strict inclusions (e.g. trees).
> ? (From looking at the admin UI I only see nested groups of the
> same name showing different versions of the same group...)
The admin UI does not show nesting. It shows the multiple versions
that are avialable for a given iu of a given id.
> - We are thinking about encrypting both the repos and the binaries, will
> the framework ,either ECF or p2, help us in that?
p2 has a mechanism of processing steps which allow for arbitrary
processing on the artifacts being dl'ed. This is how for example we are
implementing unpack200, md5 checks and other things. Check out the
ProcessingStep class.
That said depending on what you are trying to achieve you may want to
see what ECF has to offer.
> - Can you suggest a strategy on how to best filter a repos content, both
> based on users choices and entitlement? Is there a filter layer we can
> put on top of a repository or can we use special queries to achieve
> this? This one revolves around reducing the available groups/categories
> in the UI from the massive amount of available ones, also the user
> should not see any IUs (s)he won't be allowed to use later on...
Of the top of my head, I can think that the repo object you have
locally could either be something that requires authentication when loaded,
or could simply gather information from the environment, thus returning
less information.
You may want to look at MayInstall, since they have something similar
to this.
> - What are "flavors"?
Flavors is a mechanism designed to answer the question "when I
install a component, how do I discover its configuration information"? This
mechanism is mostly useful when you allow the user to dl individual bundles
and you want the configuration info to be discovered automatically
depending on the context in which the bundle is installed. In most product
scenario, like the eclipse SDK, the flavor is not necessary.
> - Why is there a separate tooling/config-IU that actually stores the
touchpoint data?
Because most of the IUs are meaning full without a context, and
adding configuration information to it would limit the context of its
reusability. For example, the org.eclipse.equinox.registry IU can be used
in many context, IDE, server side, etc and each of this context uses a
different start level for the bundle being delivered by the IU. By
separating the configuration information from the "facts" about the IU, you
augment reusability.
> - How will uninstall work for binary content (thinking about a zip that
gets unzipped during installation by the touchpoint and is not available
during uninstall time)?
If I remember correctly we remember the list of files that has been
unzipped and we delete it. I think this support could likely be improved to
be made more robust and scalable.
> - Will binary content be allowed to overwrite files (e.g.: new
> eclipse.exe rolling out will overwrite the original one)? Will this
> render uninstall/revert impossible?
This will depend on how the touchpoint action is implemented. A well
behaved touchpoint action usually makes sure that it can revert what it
does.
> I know, many dummy questions, sorry for that :)
These were actually really good questions showing that we are lacking
doc :-)
