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 |