of inconsistent-with-one-another-and-with-getdown.txt-and-limitation-ridden
'properties' and 'app_properties' mechanisms from ancient history.
Unfortunately, Sun in their infinite wisdom decided that being able to
enumerate applet parameters was "not doing it right" and provided no mechanism
for doing so. So we have to use annoying increasing int suffixes.
Use like so:
<object ..>
<param name="jvmarg0" value="-Xmx256M"/>
<param name="jvmarg1" value="-Danswer=42"/>
<param name="jvmarg2" value="-Dtrix=for kids"/>
<param name="jvmarg3" value="-Dfoodir=%APPDIR%"/>
<param name="apparg0" value="--username"/>
<param name="apparg1" value="elvis"/>
</object>
complain if you actually provide an unparseable rect or color. If you don't
provide one at all, we'll use the default.
I want people to be able to configure Getdown with just:
ui.name = My Project
and get a no-frills, but usable interface that displays download and
installation progress. Previously, this resulted in a bunch of warnings when
they tried to generate their digest.txt because they failed to supply cryptic
things like "ui.progress = 17, 321, 458, 22". I'd rather that be optional.
I may add some sort of "spurious config" warning, so that if you provide
"ui.progres = 17, 321, 458, 22" and you're wondering why things aren't working,
you don't spend hours pulling your hair out.
When I'm feeling more up to it, I'll potentially rejigger this to
allow its use if it's available, but for now just simplify it so
folks can set a single icon.
which was used by Maven, now Maven calls into the primary build to generate its
Proguarded jar file. Retired the Retroweaved jar file after a tremendous amount
of fucking around with Retroweaver. I think it's safe to say that the number of
people showing up with a 1.4 JDK operational in their browser is epsilon close
to zero.
Getdown is currently failing to create patch files because JarDiff is closing the outputstream. The attached patch comments it out, which seems to work.
moderately more sane progress indication.
It's still non-ideal, because, for example, we'll start out assuming everything
is length 1. So we'd have a queue like (1, 1, 1, 1). Then we start downloading
the first resource and see that we actually have (1500000, 1, 1, 1), so we
climb up to 99% downloading that first resource, and then we find out that we
have (1500000, 450000, 1, 1) and we pop back down to 70% or so, and so on as we
discover in turn that the web server lied to us about each file.
The alternative is to just sit at 25% for ages, then sit at 50% for ages, then
75%, etc. Maybe that's better... I guess I just like to see some sort of smooth
upward progress.
This is only a problem for me since I'm hosting a Getdown client on Github
which lies about Content-size in a HEAD request. So OOO projects will continue
to give accurate progress reports.
individually. Cap the actual download size at the reported size to ensure that
we don't end up borking our progress calculations if a web server returns a
"clever" value for content-size like 1 or 0, but then sends back real data.
Also sanitize the returned content-size in case the web server says something
awesome like -42. No one can be trusted on the Interwebs, least of all web
servers.
Michael Bayne