[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Jigdo needs concept work



Hi Chris,

thanks for your suggestions! Actually, I did all the "concept work"
long ago, but then ran into problems finding the time to turn concepts
into fact... ;)

On Mon, Dec 02, 2002 at 11:49:42AM -0500, Chris Severance wrote:
> 1. It is a GUI program, not a CLI program.

Yes! This is planned - I guess you've seen the screenshot on
atterer.net/jigdo

> 2. Jigdo only asks for a single link. The information at this link 
> maintained by the head of the system, in this case some link
> advertised at debian download page.

Well, I'm not decided on this. My current favourite idea is that the
jigdo GUI app registers itself with your web browser, so it'll pop up
when you click on the first ".jigdo" link, and if you click on another
that one will be added to a queue of requests of the running jigdo
application.

So, to download 5 images, you'll have to click 5 times, but then you
can leave it running.

(In particular, the danger with a list like the one you propose is
that jigdo might end up re-implementing functionality that an ordinary
web browser is perfectly capable of performing, like listing
information on all the available images.)

>   B. A list of every place where that stuff might be obtained
> 
> 3. The program then presents me a list of what I have, what I want, and 
> optionally, presents me a list to limit places to obtain it from.

My intention (at least in the long run) is to have jigdo pick the best
mirror automatically. (With the help of netselect.)

> Bad things that Jigdo does:
> 
> Downloads as files... like unix file names can be represented on
> other file systems!

This doesn't actually matter with the current jigdo-lite - the names
can get mangled in whatever way the OS requires.

> A separate FTP session for each file and you guys think you're
> saving something.

That's a limitation of wget - for now, use a HTTP mirror, it gives
slightly better performance.

BTW, to *really* get the same speed as with a single large download,
you need to do HTTP pipelining.

> Sounds to me like an ISO will generate half as much traffic! If you
> were really clever you'd ZIP the releases to guarantee delivery.

What exactly should we zip??

With the current jigdo-lite, almost everything that the program
downloads is compressed: The .deb files on Debian mirrors are, and
also the .jigdo and .template files.

> There are 8 links that I must feed Jigdo to get the Woody release. 
> Each 2 hour wait is rewarded with another request for a link.

Yeah, the next version of jigdo-lite features a batch mode. You'll be
able to specify an URL of (literally):

  http://www.foo.bar/debian-cd/woody-30r0-{1_NONUS,2,3,4}.jigdo

and then leave it running.

> When jigdo can meet or beat that standard it will get more popular. 
> GUI... mark-em-all... download... wake up the next morning all done!

It's a lot of work, and ATM I'm still the only person working on it...

> The Jigdo process may have been adapted to other OS but it is
> clearly designed for *nix systems.

>From the beginning, jigdo-lite was only intended to fill the gap until
the real GUI application is ready.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  CS student at the Technische  |  GnuPG key:
  | \/¯|  http://atterer.net  |  Universität München, Germany  |  0x888354F7
  ¯ '` ¯



Reply to: