From: Patrick Lauer <patrick@gentoo.org>
To: Fredrik Klasson <fredrik.k.klasson@telia.com>
Cc: gentoo-dev@robin.gentoo.org, dev-portage@gentoo.org, portage@gentoo.org
Subject: [gentoo-dev] Re: For starters.. requirements of the portage API
Date: Sun, 06 Mar 2005 13:09:39 +0100 [thread overview]
Message-ID: <1110110979.31097.23.camel@localhost> (raw)
In-Reply-To: <422AEE8A.40601@telia.com>
[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2005-03-06 12:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-06 5:27 [gentoo-dev] For starters.. requirements of the portage API Chris White
2005-03-06 12:03 ` [gentoo-dev] " Patrick Lauer
[not found] ` <422AEE8A.40601@telia.com>
2005-03-06 12:09 ` Patrick Lauer [this message]
2005-03-06 12:32 ` Jason Stubbs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1110110979.31097.23.camel@localhost \
--to=patrick@gentoo.org \
--cc=dev-portage@gentoo.org \
--cc=fredrik.k.klasson@telia.com \
--cc=gentoo-dev@gentoo.org \
--cc=gentoo-dev@robin.gentoo.org \
--cc=portage@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox