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

Enhancement: The current "Online" ZIM list always downloaded #1144

Closed
1raghavmahajan opened this issue Apr 3, 2019 · 8 comments
Closed

Enhancement: The current "Online" ZIM list always downloaded #1144

1raghavmahajan opened this issue Apr 3, 2019 · 8 comments

Comments

@1raghavmahajan
Copy link

Checklist for requesting a feature:

  • Check the issue tracker. The feature you are requesting may have already been requested. [✓]
  • Check if the feature does not exists on the latest developers version. [✓]

Is your feature request related to a problem? Please describe.

  1. The "Online" ZIM list is always downloaded whenever the library activity is opened.
  2. The full list (instead of only a few buffered items) is downloaded every time.
    Both these combined lead to a long wait time, high data usage and unnecessary server load.

Describe the solution you'd like

  1. Instead of downloading the full list only the first 30-40 items are loaded, reducing the server load and the cutting down the loading time to a fraction.

Describe alternatives you've considered

  1. A cached version of the list on the device can be used to populate the list while the differences are asynchronously updated in the background.
@kelson42
Copy link
Collaborator

kelson42 commented Apr 3, 2019

We have meanwhile an OPDS end-point https://wiki.kiwix.org/wiki/OPDS. This should be used instead of the XML file.

@1raghavmahajan 1raghavmahajan changed the title The current "Online" ZIM list always downloaded Enhancement: The current "Online" ZIM list always downloaded Apr 3, 2019
@mhutti1
Copy link
Contributor

mhutti1 commented Apr 3, 2019

Relates to #57

@1raghavmahajan
Copy link
Author

1raghavmahajan commented Apr 3, 2019

I am referring to the download and update of this list @mhutti1.
Not to updates to the currently active ZIM file as mentioned in #57 .
drawing

@1raghavmahajan
Copy link
Author

Although since the OPDS backend is ready (#57 (comment)) we could implement it on the app.
Even considering a conservative amount of usage, downloading a 6mb file multiple times a session every other day amounts to quite a lot. 6mb * 2 * 366 / 2 = ~2gb.

@1raghavmahajan
Copy link
Author

1raghavmahajan commented Apr 3, 2019

I was thinking, for this solution:

Instead of downloading the full list only the first 30-40 items are loaded, reducing the server load and the cutting down the loading time to a fraction.

Since the library.xml file is essentially flat, we can just stream the XML file rather than downloading it fully. We can parse on the go and display the result.
This can be performed using XmlPullParser (currently used), so no extra dependencies needed.

@sonusourav
Copy link
Contributor

Duplicate of #992 . Related to #683

@1raghavmahajan
Copy link
Author

1raghavmahajan commented Apr 4, 2019

  1. The full list (instead of only a few buffered items) is downloaded every time.
    Both these combined lead to a long wait time, high data usage and unnecessary server load.

is a duplicate of #683

  1. The "Online" ZIM list is always downloaded whenever the library activity is opened.

is new, as far as I know.

I am not aware of the approach in this situation @kelson42 @mhutti1 .
I would like to be assigned to this.

For now, a caching system can be implemented very easily that would only download the library when the date at http://download.kiwix.org/library/library.xml is newer than the currently downloaded version.
As for implementing the pagination we can implement OPDS or stream the XML file depending upon preference.

@kelson42
Copy link
Collaborator

I would not invest any more energy on this as using our OPDS backend in place of the library.xml will solve the problem.

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

No branches or pull requests

4 participants