Snipping quite a lot - assume an "agreed" for all that!-)
On Sat, Jan 26, 2002 at 06:20:04PM +0100, J.A. Bezemer wrote:
[snip]
> > - Hack mkhybrid to output .jigdo/.template instead of raw ISO9660
> > data. This would make the template generation a lot faster -
> > imagine daily "testing" DVD images!
>
> I don't think that'll work well. The stuff on CD has (or can have)
> quite different paths than on the mirrors, so forget the .jigdo.
Hm, two possible solutions:
- use whatever mechanism is used to generate the .list file (but
that's too Debian-CD specific)
- uniquely identify each file via its ino_t/dev_t, then check the
numbers against those of files fed to jigdo-file.
[snip]
> > - A CGI script (or mini web server, or Apache module...:) which
> > assembles the CD image on the fly from .jigdo, .template and a
> > local mirror. Essentially, this allows mirror admins to offer
> > direct HTTP downloads without the need to store the complete
> > images locally. (HTTP/1.1 ranges support would be cool.)
>
> Have jigdo-file support --start=byte --end=byte and it can probably
> be done in a small perl script (but my perl is read-only ;-)
Such a solution wouldn't be acceptable in practice: The gzipped data
would have to be unzipped repeatedly, which would get you a processor
load similar to rsync... Better "prepare" the template for HTTP
serving by unpacking its data sections into a file, and then later
pushing the data out at Tux speed with sendfile().
> > I can't be bothered to enter "write once, test everywhere" mode.
> > GCC 2.95 or 3 is available for all the important arches...
>
> Just to compare: (unextended) pascal was standardized before 1990,
> but you won't find many (if any) machines with any pascal support
> installed. Even though there's an excellent gpc. Availability isn't
> an issue, the willingness of the sysadmin to install it is.
What you say is true, but I have to find the best ratio "time spent on
jigdo / jigdo's usefulness". An overwhelming majority of CD
downloaders uses Windows or Linux - if they can use jigdo, our
problems are solved IMHO. And the remaining <3% can use direct
downloads. Any more work spent by me on improved portability doesn't
"pay off" so well.
[snip]
> > The menu stuff is the one big thing where I don't like what you've
> > done. The idea I had was eventually to have just *one* jigdo file
> > per Debian CD release. [snip]
>
> The 2.2 rev5 jigdo files combined are 3 MB unzipped and 1.02 MB gzip
> -9'd [*]. This is for 28 images. With woody, we'll have >80 images,
> so the complete jigdo will be at least about 3 MB.
>
> You know how long this takes to download over a modem? Dual-ISDN
> (128 kbit) does about 1 MB per minute, so after you start jigdo
> you'll have to wait a full three minutes to get just the menu. With
> the 56k modems doing free local calls in the US it takes more than
> twice as long. Even fast cable modems (150 KB/s) will have to wait
> longer than half a minute.
Ahem - if someone is prepared to wait for 650MB, they really ought to
be prepared to wait for 3MB...
But maybe you're interested to hear that I'll try to make jigdo (GUI
app) progressively display the info as the .jigdo is downloaded - IOW,
if all the [Image]s are near the top of the file, they will be
displayed almost immediately.
(FWIW, most of the time I only have pay-per-minute 56kbps internet
access myself.)
> This is a BIG annoyance (sorry, I mean it) -- and that while I'll
> only use less than two percent of it!! (approx 1/80'th to be
> "exact")
>
> So what I've effectively done is split your original .jigdo idea
> into the "real" .jigdo, a separate selection/menu system, and a
> separate mirror list.
...and by doing that, you're trying to re-invent the WWW. My idea is
to let jigdo register itself with browsers to it is launched when the
user clicks on a .jigdo link, so the menu system can be replaced by a
HTML page - voilá, a complete, point-and-click "menu system" supported
on every platform.
I just don't see the *need* for a fancy menu system. 80 images is too
much for a simple linear menu, true, but then what's wrong with
splitting by platform?
> And all that time, the user doesn't have to know the concept "jigdo"
> at all, he/she just downloads the CD he/she wants. Simple. Can your
> mother understand that?
Yeah, but IMHO this is even simpler:
Previosly, she clicked on an .iso link to download.
Now, she clicks on a .jigdo link to download.
> The separate mirrors.jigdo has the added advantage that Attila (or
> anyone) doesn't have to worry about it any more. There is one
> well-maintained (hopefully) mirrors list for Debian, and everyone
> can use it.
True - quite a long time ago I mentioned the possibility of an
#include directive for .jigdo files. Would you consider this a
solution to that problem?
> > The "Info" label in the [Jigdo] section would contain an
> > introductory text along the lines of "choose the correct arch, you
> > only need one out of binary-1 and binary-1-NONUS", etc. When the
> > user selects one image, that image's "Info" label would be shown.
>
> If you want fancy things like HTML formatting and "tooltip"-style
> hints,
Actually, I don't. I haven't spent a lot of time thinking about the
"*Info" labels so far.
> the menu system can easily be used for that. Use TitleHTML= and
> OptionHint= or even OptionHintHTML=. Easy. And jigdo-lite won't even
> notice.
>
> > Your menu structure also has the problem that it's a bit too flexible
> > - making a GUI app parse and display it wouldn't be impossible,
> > but I'd rather keep things simple and have just one list
> > (generated from the "ShortInfo" labels of all the "[Image]"
> > sections) showing all the available images.
>
> I refuse to believe that it would be hard to implement in a GUI app.
> If I can parse it in <100 lines of (portable!) shell code, then it
> can't be difficult. Think "web browser": instead of exiting the
^^^^^^^^^^^^^^^^^^^^
> selection on the first mouse click, just fill the selection window
> again with another list.
I *am* thinking "web browser", yes! :-)
I'm thinking "a web browser can handle this, so a web browser should",
and not jigdo.
> > We discussed this before - essentially, despite being flattered, I
> > still disagree. ;) Let rsync and HTTP/FTP mirrors co-exist with
> > jigdo throughout "woody==stable" - that way, there's enough time
> > to improve jigdo and fix bugs without being flooded by angry
> > users.
>
> I didn't yet encounter any bug (except that it didn't compile on
> !=woody). And the only way to get good testing is to force people to
> use it. Just like I did with the Kit and what Linus did with 2.4...
If you force people to switch to a new paradigm (shell instead of
point&click), the chances of them getting annoyed and refusing to use
it are pretty high, IMHO.
<shrug> Anyway, we have the HTTP/FTP mirrors _right_now_, lots of
useful donated resources - why should we throw those resources away
just like that? If those mirrors break down during the release, we can
still point people at jigdo.
> With that in mind, I'd very much like to see the webpage organized slightly
> differently:
[snip - move "smart" jigdo up before HTTP/FTP "old-fashioned" downloads]
Yeah, I might consider the jigdo beta phase over soon, and do
something like that.
(But I think there's going to be a slight format change in the
template files before that - for each file that is currently
referenced via md5sum only, I also want to add a rolling checksum. In
the future, this will make "upgrading" of images possible without
loop-mounting them.)
[snip]
> > > Finally one technical issue. Richard: I really don't know why
> > > you introduced that quoting mess in the .jigdo format specs.
> >
> > :-)
> >
> > It's because sooner or later there will be support for switches
> > after the label values. [snip]
>
> Okay, switches. But do we need switches in the Info/ShortInfo? Don't
> think so,
I agree - will fix this in the next version.
> so why use quotes there? Gets messy very quickly if you want HTML in
> Info= (note: I'd rather have that as InfoHTML then, and Info as
> plain text rendering, like the ALT= tags). Define both switches and
> quoting for individual labels, not for the entire file.
As a consequence of what I said above, I also think that "InfoHTML" is
a bad idea. I said in the jigdo-file docs to use "<p>" for line breaks
within "Info" - that idea was wrong...
Cheers,
Richard
--
__ _
|_) /| Richard Atterer | CS student at the Technische | GnuPG key:
| \/¯| http://atterer.net | Universität München, Germany | 0x888354F7
¯ '` ¯
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
