Dynamic downloads object

[m-lyon]

Would it be feasible to make the aria2p.downloads.Download class dynamic?

I.e. being able to return the current status of it's properties, not just the status when the object was first instantiated?

Below is an example of what I mean.

Using aria2p as a module, you can begin a bittorrent download via

import aria2p

# First initializing the API
api = aria2p.API(
            aria2p.Client(
            host="http://localhost",
            port=6800,
            secret=""
            )
# Then adding the magnetlink
download = api.add_magnet('some_magnet_link')

The download object returned here refers to the initial metadata download.
The download object returns 0% progress in perpetuity, even after the meta download has finished and the main download has begun.

>>> download.progress_string()
0.00%
>>> download.is_complete
False

To get the current download status you can:

# Get the GID for the download
>>> meta_gid = download.gid
# Then reinstantiate the download object for a more up-to-date status
>>> download = api.get_download(meta_gid)
>>> download.progress_string()
50%
>>> download = api.get_download(meta_gid)
>>> download.progress_string()
100%

However this is obviously less clean than just having to call the original download object.

[pawamoy]

You can use the update method to refetch data from the server.

download.update()

We could think about doing this implicitly/automatically, but I'm not sure how. With a Time-To-Live cache? How long? 1 second? Less? It could lead to inconsistent data: accessing bytes complete uses cache, then accessing "is complete" refetches data, meanwhile download finished, so status says finished but bytes say otherwise (just an example).

[m-lyon]

Potentially you could implement the donwload.update() call within the relevant properties (progress, is_complete, etc) for example:

@property
def is_complete(self):
    """Return True if download is complete."""
    self.update()
    return self.status == "complete"

Really to avoid "inconsistency" you would want to apply this to all the properties, then the properties would reflect the real time (or real time minus whatever latency) values, which I think would be more desirable than having static properties? Of course this would lead to an inconsistency between say one progress call and the next, but that is the nature of the result, the download has progressed since the last call.

I suppose it comes down to what you want the use case to be, I personally think I can see more value in a "realtime" API (and therefore acting more like a python interface for the RPC API), rather than something that periodically stores and refreshes the data cached from the RPC responses.

Does that make sense?

[pawamoy]

I agree with you, it totally makes sense 🙂

However I don't think it would help the performance to always update the download, especially in the TUI (it would generate tons of HTTP requests), so here is what I propose: we could add a convenience property on the download object, called for example u or upd or sync, which would call self.update() and return self. This way, you can still use the object as before (no breaking change), but you can also conveniently use download.u.progress or download.u.eta in places where you need "real-time" data.

What do you think?

[m-lyon]

I think that your suggestion is a good compromise between the two problems.
I'd maybe use realtime, live or current as the method name because i think download.current.progress etc sounds quite intuitive, but it's your call 🙂 .

[pawamoy]

Just released v0.8.0 with this feature 🙂

I went with live as the name!