On Thu, 2005-06-30 at 04:06 -0400, seth vidal wrote: > On Thu, 2005-06-30 at 03:59 -0400, Ignacio Vazquez-Abrams wrote: > > On Thu, 2005-06-30 at 03:39 -0400, seth vidal wrote: > > > One of the tricks I remember coming up before is sensibly representing > > > parallel downloads on a 80x25 display w/o resorting to something like > > > ncurses or snack. > > > Additionally, sensibly skipping a mirror or canceling a download in that > > > situation, as well. > > > > > > While I agree parallel downloads could speed up certain items in yum I'm > > > concerned about how complex it could make the interface. > > > > > > What do y'all think? > > > > foo-devel [### ###### ##### #### ] 53% > > > > Each segment is a parallel download. The algorithm to calculate each > > line increases in complexity, but the algorithm to display stays simple. > > > > As for skipping, kill the slowest connection and try another mirror. > > > > so wait - you're talking about downloading the SAME file in parallel? > > I don't think anyone here has been suggesting that so far and as far as > complexity goes that's WAY beyond where we started. Oh, multiple files parallel, heh. My bad. No, there's no way to represent that clearly without using at least termcap/termlib. Skipping follows the same logic though. -- Ignacio Vazquez-Abrams <ivazquez@xxxxxxxxxxxx> http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.dulug.duke.edu/pipermail/yum/attachments/20050630/e559a063/attachment-0001.bin
