Feature request: way to get sync progress from API #745

Open
opened 2014-12-12 01:56:48 +01:00 by stevedekorte · 6 comments
stevedekorte commented 2014-12-12 01:56:48 +01:00 (Migrated from github.com)

It would be nice if there were a way to get some rough measure of sync progress via the API. Something like: 1) the number of total cached messages visible on connected nodes and 2) number of cached messages on local node. This way clients could poll it to display sync progress to the user. Otherwise, they think it's broken and see no reason to leave the app open while it syncs.

It would be nice if there were a way to get some rough measure of sync progress via the API. Something like: 1) the number of total cached messages visible on connected nodes and 2) number of cached messages on local node. This way clients could poll it to display sync progress to the user. Otherwise, they think it's broken and see no reason to leave the app open while it syncs.
PeterSurda commented 2015-11-12 00:07:02 +01:00 (Migrated from github.com)

This sounds interesting.

This sounds interesting.
stevedekorte commented 2015-11-12 00:09:55 +01:00 (Migrated from github.com)

Right now I just show # of messages processed, which at least let's users see that it's doing something. What I'd really like to show is: "number of messages other nodes have told me about but I don't have yet".

Right now I just show # of messages processed, which at least let's users see that it's doing something. What I'd really like to show is: "number of messages other nodes have told me about but I don't have yet".
PeterSurda commented 2015-11-12 00:11:21 +01:00 (Migrated from github.com)

Yes that's how I understood it too. I think it would be helpful to see the progress status and I also think it is doable.

Yes that's how I understood it too. I think it would be helpful to see the progress status and I also think it is doable.
PeterSurda commented 2015-11-12 00:11:44 +01:00 (Migrated from github.com)

Do you want this shown in the UI, exposed to the API calls or both?

Do you want this shown in the UI, exposed to the API calls or both?
stevedekorte commented 2015-11-12 00:13:23 +01:00 (Migrated from github.com)

In the API. We've written our own Bitmessage UI app called Bitpost: https://voluntary.net/bitpost/

We may be doing a JS port next year and moving to the JS implementation of Bitmessage.

In the API. We've written our own Bitmessage UI app called Bitpost: https://voluntary.net/bitpost/ We may be doing a JS port next year and moving to the JS implementation of Bitmessage.
PeterSurda commented 2015-11-12 01:03:33 +01:00 (Migrated from github.com)

Look at the latest two commits in my fork (53062f61b9 and f933cea697) for guidelines how to write the API change yourself. The commits expose the number of unsynced objects to the GUI in the network tab. I don't plan on making the API change myself before 0.6, but I can merge a commit if you want to do it.

Look at the latest two commits in my fork (https://github.com/mailchuck/PyBitmessage/commit/53062f61b9eff29059bad81237161c8d4ee81ca1 and https://github.com/mailchuck/PyBitmessage/commit/f933cea697d47f700ab36c566fc6a6e31f36cfb3) for guidelines how to write the API change yourself. The commits expose the number of unsynced objects to the GUI in the network tab. I don't plan on making the API change myself before 0.6, but I can merge a commit if you want to do it.
This repo is archived. You cannot comment on issues.
1 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2025-03-02#745
No description provided.