-----Original Message-----
From: Glyn Normington [mailto:gnormington@xxxxxxxxxx]
Sent: Wednesday, February 16, 2011 10:49 AM
To: Pascal Rapicault
Cc: Virgo Project; Todorova, Katya; Stanev, Georgi
Subject: Re: Virgo& p2 use cases
Hi Pascal
On 16 Feb 2011, at 04:23, Pascal Rapicault wrote:
In this description, what is "Virgo"? The container and the
application, or just the container?
For these use cases there are currently three Virgo
deliverables that we should take into account:
Virgo web server includes the container and some
pre-installed applications: the splash screen, web admin
console, and hosted repository server.
Virgo kernel includes just the container and no apps.
Virgo Jetty server includes the container and some pre-installed apps.
Where does the use case of "the user downloads virgo,
starts it and install an application using p2" fit?
That's a good use case, but not one that I need to draw to
people's attention as it is already high on the list from a
Virgo& p2 perspective.
How much flexibility is there in terms of changing the
layout of the actual runtime to maybe make it more
"manageable" from a p2 standpoint and still accommodate the
two scenarios?
Quite a lot, some of which has been tried already. We simply
need to ensure that the user's tasks in these use cases is
not made more difficult. In particular we need to ensure that
configuration is not duplicated and that configuration is
documented as well, and edited as easily, as today's property files.
Regards,
Glyn
On 2011-02-15, at 10:33 AM, Glyn Normington wrote:
Following last week's discussion of p2, I would like to
ensure that the following use cases work when we eventually
integrate Virgo and p2:
1. Unzip and go - the user downloads and unzips Virgo,
edits config files, and runs a startup script, much like in
2.1.0. No need to invoke p2, although it is acceptable for p2
to run under the covers.
2. Provision Virgo via p2 - the user uses p2 to provision
and start Virgo.
3. "Hybrid" - the user uses p2 to provision Virgo, edits
config files, and runs a startup script, the latter two steps
much like in 2.1.0.
Regards,
Glyn