Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cabal-install needs new http download component #441

Closed
bos opened this issue May 24, 2012 · 4 comments
Closed

cabal-install needs new http download component #441

bos opened this issue May 24, 2012 · 4 comments

Comments

@bos
Copy link
Contributor

bos commented May 24, 2012

(Imported from Trac #448, reported by @dcoutts on 2009-01-10)

The way in which cabal-install currently uses the HTTP library API is quite sub-optimal. It starts a new Broswer session for each connection. This means that it cannot take advantage of HTTP pipelining, connection pooling and other goodies.

One design would involve making some HTTP download object and making requests through that. The download object would start a thread to make the actual requests. Requests would be serialised, eg using a Chan. It probably wants to work by directing URLS be downloaded to local files. On top of this we should build some caching mechanism so that we can check for example if our package index is up to date before downloading the whole thing. It would also be nice to check the length and md5 header to catch short or corrupted downloads.

Something like:

downloader :: Settings -> IO Downloader
download :: Downloader -> URL -> FilePath -> IO ()
The download function is given the URL and the local file path. If the local file exists it is taken to be the cached file. It should download the URL to a temp file in the target directory and if all successful it should atomically rename it over the target file.

Perhaps error handling needs to be more explicit than just using IOErrors.

@bos
Copy link
Contributor Author

bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-01-10)

Also needs to properly report http errors to the end user. See #545 about downloads and #549 about uploads.

@ulysses4ever
Copy link
Collaborator

I wonder if it’s still relevant. At least, I can’t find a reference Browser mentioned in the OP. Perhaps we should close this?

@Mikolaj
Copy link
Member

Mikolaj commented Aug 9, 2022

Any objections to closing this, please?

@gbaz
Copy link
Collaborator

gbaz commented Aug 10, 2022

this is definitely mainly superseded by the work for multiple backends.

@gbaz gbaz closed this as completed Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants