On 11.01.2012 14:12, Thomas Schmidt wrote:
> I think holdReady is probably the most reliable way to prevent scripts
> from messing with your DOM, although I defer to Krinkle for a more
> authoritative answer.
Yes, unless they all use that :)
My impression was that it breaks quite a few user scripts. But maybe I'm
mistaken? I havn't tested the latest version extensively.
If holdReady works well enough with other scripts, it's a good enough hack for
now, I think.
It would be
really nice if your blame engine didn't rely on character
offsets in the HTML, but used something more robust.
I did not see any error because of this so far.
As long as we know what MediaWiki does we can be responsive on that.
I would love to use something more robust, yes, but it also has to be compact
and fast. I can't think of anything offhand. Maybe
> As you said, the
> preferred implementation would be something that's close to the parser
> and puts extra annotations (like <span> tags) in the parser-generated
You talk about up to several megabytes per page.
That'S not the main problem. The main problem is that we are doing this on thje
outside. So, we would have a pre-calculated DOM with our annotations, and the
DOM present on the page without our annotations, but possibly modified by
scripts, and would have to merge the two. That only makes things wordse.
> Server-side blaming
> doesn't have to be expensive as long as you use an incremental
> blame-as-you-go implementation where you store a blame map for each
> revision, and after each edit you use the edit diff and the previous
> revision's blame map to generate the new revision's blame map.
This would be my preferred solution, but it's way beyond the scope of the
current project. The idea was to have a standalone script that works well enough
to show that this kind of thing is indeed useful.
If we have the foundation's support for developing full blame/praise support in
mediawiki, I even know who would be not only delighted but also qualified to
write it (not for free, though). But with wikidata coming up, I doubt wmde would
manage the project. Though I personally would love to see this happening asap.
In fact, I hope that some experience with the gadget based solution will
convince the foundation that yes, we want that, we need that.
Hm, actually... fellowships arn't supposed to be for development stuff, are they?
This is what Collaborativetrust already does.
Unfortunately it does it not well.
Well, the blame map they generate is better than any I have seen so far, they
deal nicely with moved paragraphs, reverts, etc. But the "trust" part is
overhead, and it's ocaml. Otoh, integrating this into mediawiki directly as an
extension was their original approach, some code already exists.
Note that storing the blame maps for all revisions needs quite a bit of space.
And yes, we need all revisions.