On Sun, 2005-03-06 at 12:50 +0100, Fredrik Klasson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chris White wrote:
> | 2) access to an internal download library built into portage (not wget
> | or some such).  This would not only allow us to do basic downloading,
> | but also address new protocols that come later on.
> uhm, just a radnom thought struck me, why re-invent the wheel? What I'm
> thinking is that, why not simply provide some Download Abstraction Layer
> (DAL) or something like that, ie, "downloadThisFileForMe(filename);"
I think that was the idea.
You tell portage "use that download wrapper" in a config file, then just
invoke "portage.fetch("URI")

> that /[cw]ould/ invoke
> ~  wget (why not? ;),
> ~  scp (maybe a bad idea),
> ~  or someother nifty file fecthing tool 
For that you might want some extra information.
E.g. if you had a diffserver (binary diffs between versions) portage has
the metadata to decide if the full file or only the diff should be
fetched. A wrapper would have to generate that metadata.
Therefore a portage-internal fetch mechanism should work better.

> (maybe even some bittorent
> client - woulnd't it be nicer to make use of p2p to fetch files at
> (hopefully) full download speed while reducing the load on the mirrors?).
Maybe bittorrent is not optimal for many small files, but there are some
simple yet effective ways of "enhancing" the file fetching.

> IMO, writing a new download library seems to me like asking for one more
> part that can be subject to Murphys law (if it can break it will),
> though, one could argue that some kind of DAL would be a great place for
> "interface bugs" (or whatever to call bugs that reside between one pice
> of software communitating with another).
Right, but you'd get a lot of extra functionality. Right now, implementing 
a new fetch mechanism is quite awkward. Having portage support for that 
would seriously help all those mechanisms.

> just my 2 öre YAFYGI ;)
How much is that in real money? ;-)

hth,
Patrick