[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] Virgo & p2 use cases
- From: Glyn Normington <gnormington@xxxxxxxxxx>
- Date: Wed, 16 Feb 2011 08:48:45 +0000
- Delivered-to: firstname.lastname@example.org
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.
> 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.