Kiwix chromebook4/27/2023 Using Wikipedia as a reference point of validated information is in all fairness, a logical choice since the platform is the most popular and by contrast, the largest source of general reference work available anywhere. With the 2016 United States election given rise to the term “Fake News,” several content-serving conglomerates like Facebook and Google have been using Wikipedia as a means to combat the onslaught of unverified information. Published by Lamin Kanteh on FebruFebruary 13, 2019 I'm convinced there must be a more efficient way to search through the directory entries without having to resort to caching data reads.Setting up Kiwix: An Offline Wikipedia Reader Once a FileReader is open, it reads data relatively quickly: the problem seems to be access. The cache cuts FileReader access during binary search by something like 90%, since it reads larger chunks of data and intercepts read requests to the file offset to return the request from memory instead of opening another FileReader. This proves, I think, that the issue is that binary search opens hundreds of instances of FileReader for each keypress during the multiple binary search "hops". Search is usable, compared to virtually unusable without the cache. It produces a significant increase in binary search speed (and image load speed) on the latest WikiMed unsplit maxi file ( wikipedia_en_medicine_maxi_2019-10.zim 1.5GB). (To test this, it may be necessary to reload the Service Worker's cached app files if the page has been visited before in the same browser: simply visit the page, wait a few seconds, exit the browser, and visit the page again.) ![]() Visiting that page in Chrome browser for Android allows testing this. ![]() I've experimentally added least-recently-used cache implementation ( ) to the kiwix-js-windows environment found here. There is no way to "pick" the file from within the app, since it only scans internal storage or an inserted microSD card (which must be FAT32, and therefore cannot hold ZIMs larger than 4GB)… When tapping on the file in the File Manager, the Kiwix app opens, but says it cannot find the ZIM. slow search and slow image extraction, though pages load "relatively" quickly.įinally, the standard Kiwix app is apparently unable to open files from an attached OTG thumb drive. Using Chrome or Edge-Chromium PWA, the large files, including the full 70GB ZIM, can be opened from the attached drive, with the same symptoms as opening WikiMed, i.e. I left it for several minutes, to no avail. It simply fails to access the file, but also then the filepicker becomes unresponsive. I used Kiwix JS Windows, installed as a PWA (Firefox recognizes and offers to install/pin it to the Home Screen, as do Chromium browsers).įirefox can open ZIMs of under 2GB from this thumb drive, but is unable to open an 18GB ZIM or the full 70GB English Wikipedia ZIM. Format is exFAT, and it is loaded by using the Paragon exFAT/NTFS tool. I tested by attaching an OTG thumb drive to an Android phone, with several sizes of ZIM on it. I think I can confirm that Firefox for Android attempts to copy the ZIM file to memory. However, this can be solved on Windows 10, because WinRT APIs can be accessed by a PWA if it is packaged for the Store or sideloaded (but not if it is installed from the Web). It has the limitation that the user must pick the ZIM each time s/he launches the app. An installable PWA of Kiwix JS Windows can be experimented with by going to in a browser that can install PWAs (Chrome or Edge-Chromium, on PC or Android). NB the aim is not to challenge the official Kiwix Android app, but to optimize support for a PWA version of our app. I note that it is claimed that WASM is supported on mobile Chrome, and therefore it might be worth experimenting with this to speed up access in mobile contexts generally, though it wouldn't make a difference to binary search. I think this could be allieviated by reading more of the title index into memory (up to a predefined limit) in order to reduce storage/disk access, but I'm guessing wildly. The same ZIM accessed with the official Android Kiwix client does not have this issue. ![]() ![]() However, slow binary search seems to be another issue because binary search does not decompress the title index (and therefore should not use xzdec), it merely accesses it on-disk repeatedly using FileReader(). The system is generally pretty slow, and I believe it is because ASM is not optimized in the Android browser. WikiMed) on a microSD card, the binary search is ridiculously slow and bugs out when backspacing in the search field (a race condition, I believe). If you open on an Android phone in Chrome or Edge-Chromium with a reasonably large ZIM (e.g. Although this is not an official target of Kiwix JS, I think this might uncover a problem in the coding of binary search.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |