W3C home > Mailing lists > Public > www-validator@w3.org > December 2008

Re: checklink: ideas for next version

From: Brett Bieber <brett.bieber@gmail.com>
Date: Tue, 16 Dec 2008 11:51:54 -0600
Message-ID: <efa010fb0812160951i6f486ce9t9900fed01d6d60cd@mail.gmail.com>
To: "olivier Thereaux" <ot@w3.org>
Cc: "www-validator Community" <www-validator@w3.org>, "Ville Skyttä" <ville.skytta@iki.fi>, "Michael Ernst" <mernst@alum.mit.edu>
On Tue, Dec 16, 2008 at 11:14 AM, olivier Thereaux <ot@w3.org> wrote:

> Hi Ville, Michael, all.
> Somewhere on my pile of "things I want to get done" there is a release of
> the link checker. Quite a few bugs have been fixed, and there was work on
> the UI, but I have been a little frustrated because some of the complaints
> about the link checker remained untouched.
> I think the #1 complaint is "it's slow", which we know comes from the fact
> that the library used to make the link checker a good web citizen,
> respecting robots.txt and all, has to wait for at least 1 second between
> requests, and we haven't managed to make it interact with the parallel agent
> module yet. But that's all wonkish excuses and it doesn't solve our problem:
> the (perceived) slowness.
> I wanted to get back to an experiment which Ville had worked on a while
> ago:
> http://qa-dev.w3.org/~ville/ack/?url=http%3A%2F%2Fqa-dev.w3.org<http://qa-dev.w3.org/%7Eville/ack/?url=http%3A%2F%2Fqa-dev.w3.org>
> I liked it quite a lot, but stumbled on the fact that it may not be very
> accessible, and that it forfeited a lot of the features of the existing link
> checker. A couple of days ago, I started looking at whether/how we could
> have the best of both worlds:
> * keep most of the current checklink architecture, including the ability to
> use as standalone, commandline tool
> * during link checking process, use DOM scripting to populate a table
> listing the links that are being checked, and the results, in real time.
> * keep the summary output in "plain" HTML, accessible and all.
> * the real time display of links being checked should help fight the
> perceived slowness (stuff happens on the page)
> How to do that:
> * code a js function to create an HTML id based on two URIs (the URI of the
> document checked and the URI of the link checked). That will be useful to
> identify table rows in the DOM
> * add a js function to add a row to the DOM with a given ID
> * add a js function to display the link in a given table cell. This
> function will be called via a <script> output while a document is being
> parsed and links-to-be-checked are discovered
> * add a js function to display the result in a table cell. This function
> will be called via a <script> output in real time as links get checked. The
> function will also apply styles on the fly to the table row or cell
> Sounds easy enough. Worth a try? Anyone interested in working on this with
> me?

Excellent. Yes... I'd be willing to help on this.

Brett Bieber
Office of University Communications
University of Nebraska-Lincoln
Received on Tuesday, 16 December 2008 17:52:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:17:57 UTC