| 1 |
On Sun, 2005-03-06 at 12:50 +0100, Fredrik Klasson wrote: |
| 2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 3 |
> Hash: SHA1 |
| 4 |
> |
| 5 |
> Chris White wrote: |
| 6 |
> | 2) access to an internal download library built into portage (not wget |
| 7 |
> | or some such). This would not only allow us to do basic downloading, |
| 8 |
> | but also address new protocols that come later on. |
| 9 |
> uhm, just a radnom thought struck me, why re-invent the wheel? What I'm |
| 10 |
> thinking is that, why not simply provide some Download Abstraction Layer |
| 11 |
> (DAL) or something like that, ie, "downloadThisFileForMe(filename);" |
| 12 |
I think that was the idea. |
| 13 |
You tell portage "use that download wrapper" in a config file, then just |
| 14 |
invoke "portage.fetch("URI") |
| 15 |
|
| 16 |
> that /[cw]ould/ invoke |
| 17 |
> ~ wget (why not? ;), |
| 18 |
> ~ scp (maybe a bad idea), |
| 19 |
> ~ or someother nifty file fecthing tool |
| 20 |
For that you might want some extra information. |
| 21 |
E.g. if you had a diffserver (binary diffs between versions) portage has |
| 22 |
the metadata to decide if the full file or only the diff should be |
| 23 |
fetched. A wrapper would have to generate that metadata. |
| 24 |
Therefore a portage-internal fetch mechanism should work better. |
| 25 |
|
| 26 |
> (maybe even some bittorent |
| 27 |
> client - woulnd't it be nicer to make use of p2p to fetch files at |
| 28 |
> (hopefully) full download speed while reducing the load on the mirrors?). |
| 29 |
Maybe bittorrent is not optimal for many small files, but there are some |
| 30 |
simple yet effective ways of "enhancing" the file fetching. |
| 31 |
|
| 32 |
> IMO, writing a new download library seems to me like asking for one more |
| 33 |
> part that can be subject to Murphys law (if it can break it will), |
| 34 |
> though, one could argue that some kind of DAL would be a great place for |
| 35 |
> "interface bugs" (or whatever to call bugs that reside between one pice |
| 36 |
> of software communitating with another). |
| 37 |
Right, but you'd get a lot of extra functionality. Right now, implementing |
| 38 |
a new fetch mechanism is quite awkward. Having portage support for that |
| 39 |
would seriously help all those mechanisms. |
| 40 |
|
| 41 |
> just my 2 öre YAFYGI ;) |
| 42 |
How much is that in real money? ;-) |
| 43 |
|
| 44 |
hth, |
| 45 |
Patrick |
Archives