Hi Arunesh,
I'd need something like findByTitle(namespace, title) in zimlib: It returns an iterator pointing
to the lexicographically next article. I'd like to use this to implement an auto suggest
feature (Same as in online wikipedia search box).
Note: While for auto suggest iterating forward is necessary, for other features it would be good if it is also
possible to iterate backward (same as in zimlib).
One other thing which may be currently missing is support for title and url search/get article
functionality. It looks to me the right now everything operates on urls and not on titles.
For searching it is necessary to also have title based functions. (Like findByTitle).
Note that while currently in most zimfiles urls have the form 'Namespace'/'Title', this is not guaranteed,
the url could be completely different from the title.
Regarding performance, have you missed Brion's and my results posted in this thread?
(They may be only in the wikitech-l@lists.wikimedia.org and not in the dev-l@openzim.org list)
Best regards,
Christian
Am 05.10.2011 08:22, schrieb Arunesh Mathur:Hi Christian,
You can look at getDirectoryInfo(String articleName, char namespace) in ZimReader.java
This'll return null if there is the article doesn't exist, else the DirectoryEntry object. (Is this what you were looking for?)
Actually I plan on adding more features if required. Do you think there are any missing, when compared to zimlib? If yes, could you list them?
Have you tested zimreader-java on an Android phone? How is it's performance?
On Mon, Oct 3, 2011 at 11:10 PM, Christian Pühringer <cip@gmx.at> wrote:
Hi Arunesh,
Firstly, thank you again for doing the java port.
I've one question regarding the features of the port:
Is there or do you plan to add a feature for iterating over the index? (Similar to find/findByTitle in C++ zimlib)
This would be required to add some auto complete feature to the phonegap app.
Best regards,
Christian
Am 24.09.2011 14:42, schrieb Arunesh Mathur:Yes, images are not compressed in ZIM files, as Emmanuel pointed out.
Also, I have tried decompressing a LZMA compressed file on an Android phone (HTC Wildfire to be precise), and the decompression speed is not a problem.
LZMA-Java is under frequent development by Lasse Collin, so we should make sure that the latest code is used.
On Sat, Sep 24, 2011 at 6:00 PM, Emmanuel Engelhart <emmanuel@engelhart.org> wrote:
On 24/09/2011 14:24, Christian Pühringer wrote:
> The JAVA liblzma performance is pretty bad: To increase efficiency of
> compression in the zim-format articles (and also all
> other data like images) are stored in clusters. Cluster size is apparently about
> 1 MB. This implies that loading an article
> which is stored at the end of a cluster involves decompressing the complete
> cluster.
Images should not be compressed in ZIM files for the obvious reasons
they mainly are already compressed. This is the case for all ZIM files I
made. As far as I know this is also the case for Mediawiki:Collection
build ZIM files.
Emmanuel
_______________________________________________
dev-l mailing list
dev-l@openzim.org
https://intern.openzim.org/mailman/listinfo/dev-l
--
Best,
Arunesh Mathur
IV year, Undergraduate,
Department of Computer Science and Engineering,
National Institute of Technology Karnataka Surathkal,
India.
_______________________________________________ dev-l mailing list dev-l@openzim.org https://intern.openzim.org/mailman/listinfo/dev-l
--
Best,
Arunesh Mathur
IV year, Undergraduate,
Department of Computer Science and Engineering,
National Institute of Technology Karnataka Surathkal,
India.