| 1 |
On Sun, 2006-04-16 at 13:38 -0700, Josh Saddler wrote: |
| 2 |
> Should do the trick; you can set up a cron job to automatically fetch |
| 3 |
> the latest snapshot. Note that you can replace [en] in the link with |
| 4 |
> the two letter language code of your choice for docs in other |
| 5 |
> languages, if desired. |
| 6 |
|
| 7 |
While somewhat useful in that these tarballs contain many more docs than |
| 8 |
fetching them one-by-one from the server over http, I'm still fetching |
| 9 |
them from the server over http, only this time I can't do it in a way |
| 10 |
that guarantees I stay current. |
| 11 |
|
| 12 |
The problem is that once a single byte in the original data has changed, |
| 13 |
the entire compressed stream differs from that byte onward, but tools |
| 14 |
like wget, curl, LWP, and so on.. don't know to rewind to the changed |
| 15 |
bytes and refetch from THAT point forward. They simply look at |
| 16 |
Content-Length and fetch from the current bytecount until they reach the |
| 17 |
end. |
| 18 |
|
| 19 |
So I'll end up fetching it with wget, then delete it, and refetch it |
| 20 |
again when I know content has changed, or when my cronjob has |
| 21 |
completed. |
| 22 |
|
| 23 |
This means I'm actually using (wasting?) MORE bandwidth than fetching |
| 24 |
the rendered HTML (or XML) versions from the server directly by checking |
| 25 |
Last-Modified headers and only fetching content when it has changed. |
| 26 |
|
| 27 |
I'll see what I can come up with to work out a better compromise to this |
| 28 |
situation. A public svn/cvs would be helpful (I've been told its coming, |
| 29 |
but "Not Ready Yet(tm)", or an rsync server to fetch the docs directly |
| 30 |
from the tree. |
| 31 |
|
| 32 |
|
| 33 |
-- |
| 34 |
David A. Desrosiers |
| 35 |
desrod@×××××××××××.com |
| 36 |
http://gnu-designs.com |
Archives