Progress callback

[LordMZTE]

It would be nice if zelda allowed for the user to provide a progress callback, that could (for example) be used to update a user interface with the download progress.

[haze]

I do want to add this feature, but it raises a bunch of questions I haven't had the time to think about:

• What would the payload of the callback look like (what should it contain?)
• How often is this callback called? Should that be configurable?
• Should we instead expose the reader for the body and let the user do it themselves

I definitely think zelda errs more on the easy side, but I wouldn't mind handing users more power

[LordMZTE]

I think both approaches are good. I don't think it would be a problem, if we called the callback as often as possible. If the user wants some sort of rate limit, that's easy enough to implement manually.

As for how the function should look, I think it would be best to go for some sort of dynamically dispatched solution, similar to std.mem.Allocator. Obviously, there's a ton of ways to do this in zig, and I can't really recommend one here, as I don't know that much about zelda yet. I recommend you look into the different approaches and find the best one for this use-case.

Your alternative solution of exposing the reader is probably also an amazing feature, but I believe it should be a seperate issue. Especially in my use case, this would be extremely useful, as I'm downloading a .tar.xz archive, and with this API, I might even be able to decompress and write the data to disk as it arrives (how cool is that? :P).

[haze]

As for how the function should look, I think it would be best to go for some sort of dynamically dispatched solution, similar to std.mem.Allocator. Obviously, there's a ton of ways to do this in zig, and I can't really recommend one here, as I don't know that much about zelda yet. I recommend you look into the different approaches and find the best one for this use-case.

I think I was more asking about the function prototype for the callback. I don't think we need more complex dispatch (because you can implement that yourself in the single supplied callback)

Your alternative solution of exposing the reader is probably also an amazing feature...

Would exposing the raw reader not solve the callback problem / use case? In my eyes it would be a bit more involved (and Zelda aims to be as simple as possible)

Anyways I might not be able to work on this, this very moment, but it's definitely planned