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

Implement more efficient way of submitting highlights #16

Open
marcus-crane opened this issue Feb 7, 2022 · 4 comments
Open

Implement more efficient way of submitting highlights #16

marcus-crane opened this issue Feb 7, 2022 · 4 comments
Labels
enhancement New feature or request
Milestone

Comments

@marcus-crane
Copy link
Owner

marcus-crane commented Feb 7, 2022

At the moment, everything is just fired off to Readwise.

This is fine but as your Kobo highlights grow, the upload process will naturally become slower.

I was thinking that you could easily tell if a book hasn't changed (and finished books don't) by simply saving hashes for books and seeing if they've changed. We kind of need to retain what content has actually been submitted (not just number of bookmarks) since highlight positions and text annotations can change after the fact.

If they have changed then we ideally just figure out what items are new so perhaps we just hash each bookmark.

It all falls down if someone either is doing a first upload with a squillion highlights (these should be chunked to avoid rate limiting) and/or they use a new computer with a previous upload DB.

It's really cheap to make database calls but expensive (relatively speaking) to fire JSON across the web.

@marcus-crane marcus-crane added the enhancement New feature or request label Feb 7, 2022
@marcus-crane marcus-crane added this to the v1.0.0 milestone Feb 7, 2022
@marcus-crane
Copy link
Owner Author

The side effect of #19 relates here.

Upon submitting highlights, we need to persist the Readwise IDs to disc, probably mapped to VolumeID. Upon sending new highlights, we need to get the book from Readwise (to see if the title has updated) and use that title so we don't overwrite the users choice or send a duplicate entry.

@marcus-crane
Copy link
Owner Author

Oh, I dunno why it never occured to me but the sync history can just be stored on the Kobo device given it's effectively a USB 🤦 It also means that if you use October on a new computer, it can pick up where it left off instead of blinding syncing everything from scratch.

@marcus-crane
Copy link
Owner Author

I think this can be pushed to post v1.0.0. It's good enough for an initial release.

@marcus-crane marcus-crane modified the milestones: v1.0.0, future Mar 13, 2022
@marcus-crane marcus-crane modified the milestones: future, v2.0.0 May 20, 2022
@oleestar
Copy link

The USB storage feature, to be able to use October on different devices, would be helpful. Now I make sure I only sync it from my desktop, but I would love to sync it also from my laptops.

Otherwise, there are usually two types of users:
a) Keep all the books on the Kobo, and therefore have a gigantic libarary of ebooks to sync
b) Keep only a few books on the Kobo, which are being read - so the library is small

I used to do a), but I found if I keep only a few books on the Kobo, I read more, and finish them faster, as there is more focus to read.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants