| Age | Commit message (Collapse) | Author |
|---|
|
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
|
|
|
|
|
|
|
|
|
|
This patch adds the ability for ProtocolServer clients to specify which
HTTP method to use, and also to include an optional HTTP request body.
|
|
This finally takes care of the kind-of excessive boilerplate code that were the
ctype adapters. On the other hand, I had to link `LibC/ctype.cpp` to the Kernel
(for `AK/JsonParser.cpp` and `AK/Format.cpp`). The previous commit actually makes
sense now: the `string.h` includes in `ctype.{h,cpp}` would require to link more LibC
stuff to the Kernel when it only needs the `_ctype_` array of `ctype.cpp`, and there
wasn't any string stuff used in ctype.
Instead of all this I could have put static derivatives of `is_any_of()` in the
concerned AK files, however that would have meant more boilerplate and workarounds;
so I went for the Kernel approach.
|
|
|
|
This patch just applies a suggestion, making the code more readable.
|
|
The whole thing with `pro url > filename` was getting annoying, so let's
just have it support Content-Disposition and guessing from the URL.
|
|
|
|
Clients now receive HTTP status codes like 200, 404, etc.
Note that a 404 with content is still considered a "successful"
download from ProtocolServer's perspective. It's up to the client
to interpret the status code.
I'm not sure if this is the best API, but it'll work for now.
|
|
|
|
We now store the response headers in a download object on the protocol
server side and pass it to the client when finishing up a download.
Response headers are passed as an IPC::Dictionary. :^)
|
|
Also updates `pro` to display download progress and speed on stderr
|
|
StartDownload requests for unhandled protocols (or invalid URLs) will
now refuse to load instead of asserting. A failure code is sent back
to LibProtocol and Protocol::Client::start_download() returns nullptr.
Fixes #1604.
|
|
|
|
|
|
I've been wanting to do this for a long time. It's time we start being
consistent about how this stuff works.
The new convention is:
- "LibFoo" is a userspace library that provides the "Foo" namespace.
That's it :^) This was pretty tedious to convert and I didn't even
start on LibGUI yet. But it's coming up next.
|
|
As suggested by Joshua, this commit adds the 2-clause BSD license as a
comment block to the top of every source file.
For the first pass, I've just added myself for simplicity. I encourage
everyone to add themselves as copyright holders of any file they've
added or modified in some significant way. If I've added myself in
error somewhere, feel free to replace it with the appropriate copyright
holder instead.
Going forward, all new source files should include a license header.
|
|
This always felt out-of-place in LibC.
|
|
LibProtocol::Client::start_download() now gives you a Download object
with convenient hooks (on_finish & on_progress).
Also, the IPC handshake is snuck into the Client constructor, so you
don't need to perform it after instantiating a Client.
This makes using LibProtocol much more pleasant. :^)
|
|
Also, don't print anything other than the download payload to stdout.
This gives us a very simple HTTP download utility :^)
|
|
The DownloadFinished message from the server now includes a buffer ID
that can be mapped into the client program.
To avoid prematurely destroying the buffer, the server will hang on to
it until the client lets it know that they're all good. That's what the
ProtocolServer::DisownSharedBuffer message is about.
In the future it would be nice if the kernel had a mechanism to allow
passing ownership of a shared buffer along with an IPC message somehow.
|
|
|
