Re: [Wikitech-l] Disambiguation while editing
On 9/30/09 7:30 PM, Steve Bennett wrote: > On 10/1/09, Brion Vibber wrote: >> I'm pretty sure the usability kids have something to this effect up >> their sleeves, hiding somewhere. > > Heh, I was wondering if this would start to become the new meme. "We > don't need to fix that gui, the usability team will take care of it!" Oh things need fixin' all right. :) Just want to make sure that efforts are combined, not duplicated. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/30/09 5:59 PM, Aryeh Gregor wrote: [snip] > Of course, this can get ugly if you later want to add more > capabilities to the format, so JSON or YAML might make sense, but XML > is overboard IMO. I'd use XML for text markup only, if that. > > But no point in bikeshedding -- if this gets done, whoever does it > gets to decide the format. Yep. :) The main reasons to look at XML specifically (vs say JSON which is also available built-in for both our server and client sides) is that building a structure that's localization-friendly is straightforward, since you can easily tack on a 'lang' attribute. This could be done in JSON but probably with a different tree structure. Given we already had a proposed XML structure designed at the start of this thread (based in part on the previous work on German Wikipedia), I don't see much reason to continue talking formats unless there's an alternative structure proposal with solid benefits. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)
... that makes sense .. ( on the side I was looking into a fall-back ogg video serving solution that would hit the disk issue) .. but in this context your right .. its about saturating the network port Since network ports are generally pretty fast, a test on my laptop may be helpful: (running PHP 5.2.6-3ubuntu4.2 & Apache/2.2.11 Intel Centrino 2Ghz ) Lets take a big script-loader request running from "memory" say the firefogg advanced encoder javascript set (from the trunk...I made the small modifications Tim suggested ie (don't parse the javascript file to get the class list) #ab -n 1000 -c 100 "http://localhost/wiki_trunk/js2/mwEmbed/jsScriptLoader.php?urid=18&class=mv_embed,window.jQuery,mvBaseUploadInterface,mvFirefogg,mvAdvFirefogg,$j.ui,$j.ui.progressbar,$j.ui.dialog,$j.cookie,$j.ui.accordion,$j.ui.slider,$j.ui.datepicker"; result is: Concurrency Level: 100 Time taken for tests: 1.134 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 64019000 bytes HTML transferred: 63787000 bytes Requests per second:881.54 [#/sec] (mean) Time per request: 113.437 [ms] (mean) Time per request: 1.134 [ms] (mean, across all concurrent requests) Transfer rate: 55112.78 [Kbytes/sec] received So we are hitting near 900 request per second on my 2 year old laptop. Now if we take the static minified combined file which is 239906 instead of 64019 bytes we should of-course get much higher RPS going direct to apache: #ab -n 1000 -c 100 http://localhost/static_combined.js Concurrency Level: 100 Time taken for tests: 0.604 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 240385812 bytes HTML transferred: 240073188 bytes Requests per second:1655.18 [#/sec] (mean) Time per request: 60.416 [ms] (mean) Time per request: 0.604 [ms] (mean, across all concurrent requests) Transfer rate: 388556.37 [Kbytes/sec] received Here we get near 400MBS and around 2x times the Request per second... At a cost of about 1/2 as many requests you can send the content to people 3 times as small (ie faster). Of course none of this applies to wikimedia setup where these would all be squid proxy hits. \ I hope this shows that we don't necessarily "have to" point clients to static files, and that php pre-processing the cache is not quite as costly as Tim outlined (if we setup an entry point that first checks the disk cache before loading in all of mediaWiki php ) Additionally most mediaWiki installs out there are probably not serving up thousands of request per second. (and those that are are probably have proxies setup).. So the gziping php proxy of js requests is worth while. --michael Aryeh Gregor wrote: > On Wed, Sep 30, 2009 at 3:32 PM, Michael Dale wrote: > >> Has anyone done any scalability studies into minimal php @readfile >> script vs apache serving the file. Obviously apache will server the file >> a lot faster but a question I have is at what file size does it saturate >> disk reads as opposed to saturated CPU? >> > > It will never be disk-bound unless the site is tiny and/or has too > little RAM. The files can be expected to remain in the page cache > perpetually as long as there's a constant stream of requests coming > in. If the site is tiny, performance isn't a big issue (at least not > for the site operators). If the server has so little free RAM that a > file that's being read every few minutes and is under a megabyte in > size is consistently evicted from the cache, then you have bigger > problems to worry about. > > ___ > 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] Disambiguation while editing
Lars Aronsson wrote: > In the edit box, when I type [[John Doe]], I want some chance to > verify that I'm linking to the right article, whether it is a > disambiguation page, or by seeing the first sentence from that > article. I know I can "preview" my edit and click that link to > see the page (or ctrl-click to make it appear in a new tab), but > that method just seems sooo 2002. Bug 8339: show them with a different color so you can spot them directly at preview. https://bugzilla.wikimedia.org/show_bug.cgi?id=8339 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disambiguation while editing
On 10/1/09, Magnus Manske wrote: > Meanwhile, I wrote a simple JS that tells you when the cursor (in edit > mode) is within a "red link", or if it's a disambiguation page, it > offers "replace-links" to click on. That should answer the problem of > the OP. Could do redirects as well, but didn't want to overload it... IMHO, you should "overload" it. You write lots of brilliant little tools that do distinct jobs. You should combine them into big chunks of really useful functionality, the "Magnus toolbelt" or something. Then more people would come across more of these features and demand that they be integrated into MediaWiki... Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disambiguation while editing
On Thu, Oct 1, 2009 at 11:22 AM, Roan Kattouw wrote: > 2009/10/1 Brion Vibber : >> I'm pretty sure the usability kids have something to this effect up >> their sleeves, hiding somewhere. >> > Sort of. We have a link insertion dialog that shows title suggestions > and page existence status as you type in our Babaco release, which > should be deployed very soon, and we have ideas about adding a link > preview to that dialog. We originally envisaged "link preview" to mean > a preview of what the actual link looks like, but having a preview of > the linked-to page, if it exists, sounds like an interesting idea. > I've forwarded the original post to the rest of our team, and I'll > point them to the rest of this thread as well. Meanwhile, I wrote a simple JS that tells you when the cursor (in edit mode) is within a "red link", or if it's a disambiguation page, it offers "replace-links" to click on. That should answer the problem of the OP. Could do redirects as well, but didn't want to overload it... http://en.wikipedia.org/wiki/User:Magnus_Manske/linkfixr.js Cheers, Magnus ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disambiguation while editing
2009/10/1 Brion Vibber : > I'm pretty sure the usability kids have something to this effect up > their sleeves, hiding somewhere. > Sort of. We have a link insertion dialog that shows title suggestions and page existence status as you type in our Babaco release, which should be deployed very soon, and we have ideas about adding a link preview to that dialog. We originally envisaged "link preview" to mean a preview of what the actual link looks like, but having a preview of the linked-to page, if it exists, sounds like an interesting idea. I've forwarded the original post to the rest of our team, and I'll point them to the rest of this thread as well. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disambiguation while editing
On Thu, Oct 1, 2009 at 8:55 AM, Tei wrote: > On Thu, Oct 1, 2009 at 12:37 AM, Lars Aronsson wrote: >> >> In the edit box, when I type [[John Doe]], I want some chance to >> verify that I'm linking to the right article, > > Humm? > > I don't know the wikipedia, but on other wikis is like that: (snip) The issue was about disambiguations, that is, the case where one term has two meanings. [[John Doe]] may lead you to an article about another person than you intended to, but with the same name. Or to a page only specifying that there are several people by that name, and giving you links to the various articles. -- André Engels, andreeng...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
