On Thu, Apr 10, 2008 at 1:10 PM, Bart Smaalders <[EMAIL PROTECTED]> wrote: > Yes. Right now, though, we're trying more to get the basics working > well. Because Python's threading support is somewhat rudimentary > compared to what we're used to, and because we want to explore > alternative transports such as peer-to-peer, etc, I'm more inclined to > split off the download and uncompress portions completely. When we > get
Heh... I'd been thinking about P2P for this as well but figured that everyone would think I was loony for even suggesting it. > There's also the need for local caches of files so that repeated zone > installations don't always download from the repository; this sort of > caching is also very handy for doing installs over wireless, Comcast, > and other networks of dubious reliability/integrity. Since we retrieve > files by hash, and the hash will be easily locally verifiable against > the signed manifests, our transports need not be all SSL to the > mothership. Would throwing in multicast earn me a spot in the loony bin? Imagine an ad-hoc wireless network set up for an installfest if each machine were able to grab the bits it needed from a multicast P2P network. The important part here is to minimize the number of times that bits go over a limited bandwidth network with a large number of consumers. In the enterprise, this could make it so that machines could rather passively keep a (almost?) fully populated cache for zone installs, upgrades, etc. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
