Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application
Petr, do you think it would be an option to use git version control as a storage format instead of openzim? Which would facilitate edit and merge back changes? Rupert On Jan 23, 2015 11:59 AM, Petr Bena benap...@gmail.com wrote: Hi, I know most of you hate reinventing a wheel so I first send it here, before I launch that project :) Some of you probably know kiwix - kiwix.org which is offline wikipedia reader. I think the idea of this reader is cool, most of you probably sometimes wanted to access wikipedia while being offline somewhere, but couldn't. Kiwix can help with this, however it has one big problem and solution for it is so complex that it would basically need a rewrite of whole thing. That problem is that you need to download pretty huge file (40+GB) in order to use it for en wikipedia for example. And if you wanted to update those few wikipages you are interested in, to a latest revision, then you again need to download that huge file. That suck. Especially with GPRS internet and similar connectivity and it also suck because mobile phones don't even have space for so much data. My idea is to create app similar to kiwix, that would use SQLite DB and using wikipedia API it would (slowly, apache friendly) download contents of any mediawiki installation based on user selection, so that you could download just a 1 page for offline reading, or 1 category. Or 1000 categories. Or precompiled sets of pages created by users (books). You could easily update these using API anytime to latest version. You could get media files for these pages, etc, etc... (You could probably even edit the pages offline, and then update them when you are online, but that is just extra feature) I think this approach would work much better and it's sad kiwix already doesn't support it. At some point, if it worked I think this new code could be merged back into kiwix, I am going to use C++ in the end, which kiwix uses as well. What do you think about it, is it worth of working on? Is there actually a community of offline wikipedia readers that would appreciate it? Thanks ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application
I don't really know, it is technically possible but probably not suitable. I don't want to create offline wiki. Just a reader of a wiki, so no complex versioning is required for that. On Sun, Jan 25, 2015 at 6:00 PM, rupert THURNER rupert.thur...@gmail.com wrote: Petr, do you think it would be an option to use git version control as a storage format instead of openzim? Which would facilitate edit and merge back changes? Rupert On Jan 23, 2015 11:59 AM, Petr Bena benap...@gmail.com wrote: Hi, I know most of you hate reinventing a wheel so I first send it here, before I launch that project :) Some of you probably know kiwix - kiwix.org which is offline wikipedia reader. I think the idea of this reader is cool, most of you probably sometimes wanted to access wikipedia while being offline somewhere, but couldn't. Kiwix can help with this, however it has one big problem and solution for it is so complex that it would basically need a rewrite of whole thing. That problem is that you need to download pretty huge file (40+GB) in order to use it for en wikipedia for example. And if you wanted to update those few wikipages you are interested in, to a latest revision, then you again need to download that huge file. That suck. Especially with GPRS internet and similar connectivity and it also suck because mobile phones don't even have space for so much data. My idea is to create app similar to kiwix, that would use SQLite DB and using wikipedia API it would (slowly, apache friendly) download contents of any mediawiki installation based on user selection, so that you could download just a 1 page for offline reading, or 1 category. Or 1000 categories. Or precompiled sets of pages created by users (books). You could easily update these using API anytime to latest version. You could get media files for these pages, etc, etc... (You could probably even edit the pages offline, and then update them when you are online, but that is just extra feature) I think this approach would work much better and it's sad kiwix already doesn't support it. At some point, if it worked I think this new code could be merged back into kiwix, I am going to use C++ in the end, which kiwix uses as well. What do you think about it, is it worth of working on? Is there actually a community of offline wikipedia readers that would appreciate it? Thanks ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sane versioning for core (was: Re: Fwd: No more Architecture Committee?)
+1 for something like this. Its not a huge problem not to do semver but it'd be simpler to explain if we did. On Sun, Jan 25, 2015 at 10:27 AM, Legoktm legoktm.wikipe...@gmail.com wrote: On 01/15/2015 08:26 PM, Chad wrote: I've been saying for over a year now we should just drop the 1. from the 1.x.y release versions. So the next release would be 25.0, 26.0, etc etc. +1, let's do this. It would allow us to follow semver and still retain our current version number history instead of waiting for a magical 2.0. -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sane versioning for core (was: Re: Fwd: No more Architecture Committee?)
On 01/15/2015 08:26 PM, Chad wrote: I've been saying for over a year now we should just drop the 1. from the 1.x.y release versions. So the next release would be 25.0, 26.0, etc etc. +1, let's do this. It would allow us to follow semver and still retain our current version number history instead of waiting for a magical 2.0. -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application
The storage format is very efficient and there is a c library for it : https://libgit2.github.com It should be not necessary to create complex versioning around it. You plan to store html or wikitext? Rupert On Jan 25, 2015 6:37 PM, Petr Bena benap...@gmail.com wrote: I don't really know, it is technically possible but probably not suitable. I don't want to create offline wiki. Just a reader of a wiki, so no complex versioning is required for that. On Sun, Jan 25, 2015 at 6:00 PM, rupert THURNER rupert.thur...@gmail.com wrote: Petr, do you think it would be an option to use git version control as a storage format instead of openzim? Which would facilitate edit and merge back changes? Rupert On Jan 23, 2015 11:59 AM, Petr Bena benap...@gmail.com wrote: Hi, I know most of you hate reinventing a wheel so I first send it here, before I launch that project :) Some of you probably know kiwix - kiwix.org which is offline wikipedia reader. I think the idea of this reader is cool, most of you probably sometimes wanted to access wikipedia while being offline somewhere, but couldn't. Kiwix can help with this, however it has one big problem and solution for it is so complex that it would basically need a rewrite of whole thing. That problem is that you need to download pretty huge file (40+GB) in order to use it for en wikipedia for example. And if you wanted to update those few wikipages you are interested in, to a latest revision, then you again need to download that huge file. That suck. Especially with GPRS internet and similar connectivity and it also suck because mobile phones don't even have space for so much data. My idea is to create app similar to kiwix, that would use SQLite DB and using wikipedia API it would (slowly, apache friendly) download contents of any mediawiki installation based on user selection, so that you could download just a 1 page for offline reading, or 1 category. Or 1000 categories. Or precompiled sets of pages created by users (books). You could easily update these using API anytime to latest version. You could get media files for these pages, etc, etc... (You could probably even edit the pages offline, and then update them when you are online, but that is just extra feature) I think this approach would work much better and it's sad kiwix already doesn't support it. At some point, if it worked I think this new code could be merged back into kiwix, I am going to use C++ in the end, which kiwix uses as well. What do you think about it, is it worth of working on? Is there actually a community of offline wikipedia readers that would appreciate it? Thanks ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application
Either only wikitext or both, at least until I would get some wikitext to html convertor lib On Sun, Jan 25, 2015 at 7:41 PM, rupert THURNER rupert.thur...@gmail.com wrote: The storage format is very efficient and there is a c library for it : https://libgit2.github.com It should be not necessary to create complex versioning around it. You plan to store html or wikitext? Rupert On Jan 25, 2015 6:37 PM, Petr Bena benap...@gmail.com wrote: I don't really know, it is technically possible but probably not suitable. I don't want to create offline wiki. Just a reader of a wiki, so no complex versioning is required for that. On Sun, Jan 25, 2015 at 6:00 PM, rupert THURNER rupert.thur...@gmail.com wrote: Petr, do you think it would be an option to use git version control as a storage format instead of openzim? Which would facilitate edit and merge back changes? Rupert On Jan 23, 2015 11:59 AM, Petr Bena benap...@gmail.com wrote: Hi, I know most of you hate reinventing a wheel so I first send it here, before I launch that project :) Some of you probably know kiwix - kiwix.org which is offline wikipedia reader. I think the idea of this reader is cool, most of you probably sometimes wanted to access wikipedia while being offline somewhere, but couldn't. Kiwix can help with this, however it has one big problem and solution for it is so complex that it would basically need a rewrite of whole thing. That problem is that you need to download pretty huge file (40+GB) in order to use it for en wikipedia for example. And if you wanted to update those few wikipages you are interested in, to a latest revision, then you again need to download that huge file. That suck. Especially with GPRS internet and similar connectivity and it also suck because mobile phones don't even have space for so much data. My idea is to create app similar to kiwix, that would use SQLite DB and using wikipedia API it would (slowly, apache friendly) download contents of any mediawiki installation based on user selection, so that you could download just a 1 page for offline reading, or 1 category. Or 1000 categories. Or precompiled sets of pages created by users (books). You could easily update these using API anytime to latest version. You could get media files for these pages, etc, etc... (You could probably even edit the pages offline, and then update them when you are online, but that is just extra feature) I think this approach would work much better and it's sad kiwix already doesn't support it. At some point, if it worked I think this new code could be merged back into kiwix, I am going to use C++ in the end, which kiwix uses as well. What do you think about it, is it worth of working on? Is there actually a community of offline wikipedia readers that would appreciate it? Thanks ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sane versioning for core (was: Re: Fwd: No more Architecture Committee?)
On Sun, Jan 25, 2015 at 1:27 PM, Legoktm legoktm.wikipe...@gmail.com wrote: On 01/15/2015 08:26 PM, Chad wrote: I've been saying for over a year now we should just drop the 1. from the 1.x.y release versions. So the next release would be 25.0, 26.0, etc etc. -1 from me, for what little that's worth... It would allow us to follow semver and still retain our current version number history instead of waiting for a magical 2.0. This logic is the opposite of semver. Semver says you only bump the major version number when you make a breaking change. Since breaking changes are Bad Things, therefore bumping the major version number is also a Bad Thing. It is something that you should strive to *avoid* having to do. Under semver, a version number of the form 1.large integer is a *badge of honor*. It means that you have successfully executed many releases *without* needing to make a breaking change. One should display that initial 1. proudly; one should not consider it to be superfluous. zw ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [RfC] Improving extension dependency management and versioning
Hi! I've written up an RfC[1] discussing the pain points for managing extensions and suggestions on how to improve it. Comments and feedback appreciated! [1] https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sane versioning for core
On 01/25/2015 06:04 PM, Zack Weinberg wrote: On Sun, Jan 25, 2015 at 1:27 PM, Legoktm legoktm.wikipe...@gmail.com wrote: On 01/15/2015 08:26 PM, Chad wrote: I've been saying for over a year now we should just drop the 1. from the 1.x.y release versions. So the next release would be 25.0, 26.0, etc etc. -1 from me, for what little that's worth... It would allow us to follow semver and still retain our current version number history instead of waiting for a magical 2.0. This logic is the opposite of semver. Semver says you only bump the major version number when you make a breaking change. Since breaking changes are Bad Things, therefore bumping the major version number is also a Bad Thing. It is something that you should strive to *avoid* having to do. Except that every 1.x release *does* contain breaking changes. If we followed semver we would be bumping the major version, but we don't. -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sane versioning for core
On 2015-01-25 6:04 PM, Zack Weinberg wrote: On Sun, Jan 25, 2015 at 1:27 PM, Legoktm legoktm.wikipe...@gmail.com wrote: On 01/15/2015 08:26 PM, Chad wrote: I've been saying for over a year now we should just drop the 1. from the 1.x.y release versions. So the next release would be 25.0, 26.0, etc etc. -1 from me, for what little that's worth... It would allow us to follow semver and still retain our current version number history instead of waiting for a magical 2.0. This logic is the opposite of semver. Semver says you only bump the major version number when you make a breaking change. Since breaking changes are Bad Things, therefore bumping the major version number is also a Bad Thing. It is something that you should strive to *avoid* having to do. Under semver, a version number of the form 1.large integer is a *badge of honor*. It means that you have successfully executed many releases *without* needing to make a breaking change. One should display that initial 1. proudly; one should not consider it to be superfluous. zw Whether fortunate or not 25.0, 26.0, etc... in reality is much closer to semver than you think. We passed semver 1.x years ago. Our releases are made over periods of 6 months or sometimes a whole year. With this period nearly every one of our releases includes at least one breaking change somewhere in the code. We even have a dedicated breaking change section in the release notes. Semver is a nice ideal. And for most libraries it works well, since they have defined APIs and are explicitly intended to consumed by other software and versions are directly used to control problems. But MediaWiki is an application, and a large one at that. It's consumed in a completely different way and if you were actually versioning it there are actually multiple surfaces you would want to version which are almost isolated from the actual release version number. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
