[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: Glyn Normington <gnormington@xxxxxxxxxx>
- Date: Wed, 23 Mar 2011 05:29:52 -0700
- Delivered-to: firstname.lastname@example.org
I attach the notebook pages from yesterday's meeting as a memory-jogger.
I have addressed this to virgo-dev to keep others in the loop. This was a meeting to discuss the p2 support in Virgo 3.0 while most of the committers (all except Dmitry) and some p2 experts (copied) were at EclipseCon.
Here are some ideas I've had following the meeting. What do you think?
I think we can configure the kernel to have a "managed user region" by starting it with a Repository (the Virgo type) backed by p2 instead of the usual repository/ext and repository/usr. The p2 Repository (sorry if this term is confusing!) could internally represent its physical artifacts in a p2-oriented manner as we discussed and then reconstitute them into the form that Virgo understands today when the artifacts are returned to Virgo from Repository accesses.
The crucial property of a p2 Repository is that it is constant across warm starts of Virgo, so we have the possibility of recovering the runtime state rather than having to re-deploy everything. (The reason we have to re-deploy everything on warm restart today is because repository/ext, repository/usr, and pickup may have been changed while Virgo was down.)
We also need the Virgo p2 support to drive the deployer API during cold start to deploy the relevant applications. (Note that this is applications plural since the web support is an application that we'll need in addition to the user's application.)
We also need to control hot deployment in this set up. It may be as simple as turning off the hot deployer.