On Sun, Dec 6, 2009 at 6:56 PM, John Doe <phoenixoverride(a)gmail.com> wrote:
or a simpler method would be to use a javascript tool
like I use which
was created by lupin called popups which can actually get the redirect
target page show the first picture and first paragraph on mouse hover
You have a weird definition of simpler. :) Thousands of lines of JS code
and an additional HTTP request per link isn't simple in my book. :)
Though the popups tool does provide a number of other advantages which
justify its load and complexity... are you aware of any large
mediawiki install which have this tool activated by default (i.e.
for anons?)
On Sun, Dec 6, 2009 at 6:45 PM, Aryeh Gregor
<Simetrical+wikilist(a)gmail.com> wrote:
Caching is one problem here. Another is that you need
to reliably
generate the "redirected from" link somehow, so that redirects are
maintainable. You don't want an editor to click a link, arrive at a
totally different page (maybe via an inappropriate redirect), and have
no idea how they got there.
hm. This could be resolved by mixing in the URL stuffing alternative,
linking to /target#from_redirectname then letting client side JS code
generate the redirect back-link.
The job queue is already horribly overloaded, I
don't think adding
more things to it would be a good thing.
Right… though it's not especially harmful if this information is stale so
there is the possibility of simply letting it be stale.
...but workqueue workload is why I waved my arms about request merging and
priority queueing. I'd expect that the actual additional work in fixing up
redirect destination changes would be pretty negligible if the entries
were handled at a lower priority and eliminated whenever their task
was completed as a side effect of some other change.
On the other hand, since
this particular change doesn't affect anything visible to templates or
such, you wouldn't have to reparse the whole page to update it, in
principle.
[snip]
Good point.