W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > April 2009

mobileOK Checker library overhaul: changes committed

From: Francois Daoust <fd@w3.org>
Date: Fri, 10 Apr 2009 16:07:20 +0200
Message-ID: <49DF5298.6000105@w3.org>
To: public-mobileok-checker <public-mobileok-checker@w3.org>

As agreed, I put my initial plan to make the library truly extensible 
[1] into action. I had to make a few adjustments to make it work. There 
was no real way to divide the work, so I just went ahead and did it. I 
just committed the changes.

The new version passes the test suite (or rather it does not, but tests 
that fail actually reveal bugs of the previous version, see bugs 6797 
[2] and 6798 [3]), but I would not call it a fully stable version at 
this point. I put a list of TODOs in the code, mostly related to the way 
"unusual" cases are handled. Most of them were actually already TODOs in 
the former version.

I'll probably do a series of small commits in the upcoming days. Code 
review and comments welcome!

Most of the classes that composed the preprocessing step are now gone, 
replaced by a new hierarchy of classes. One thing to realize is that the 
*actual* code is the same as before. I just re-factored it a bit (maybe 
more than just a bit).

I re-generated the Javadoc of the library. It contains a more detailed 
description of how things now work:

This is where changes in the way the Checker retrieves, decodes and 
parses resources can be introduced.
This is also where the list of tests the Checker is to run on the moki 
representation should go.
The MobileOKConfiguration static class generates the mobileOK-compliant 
configuration profile, used by default.

moki schema
I haven't changed anything in the moki schema (yet).
The re-factoring revealed a small number of slight inconsistencies. 
Nothing to really worry about. I'll raise another thread on that for 
later updates.

This was not the goal of the re-factoring, and I haven't checked the 
impact yet, but the new version should be much more efficient in terms 
of multi-threading. Previous version downloaded stylesheets using 
multi-threading, then images, then objects and then links. The new 
version retrieves all resources in parallel (except for objects that 
require some special treatment to match our wonderful object element 
processing rule).

Also, the previous version had no limit in terms of threads, leading to 
situations where 150 threads could be running concurrently to retrieve 
resources. That sounded a bit aggressive and inefficient. I set a 
maximum limit of 5 threads at a time. Most of the resources associated 
with a given resource are likely to come from the same origin.

Adding support for the file scheme
See how this can be done at the end of the description in the Javadoc:

In the end, I don't think that adding a new test outcome is actually 
required. Support for the file scheme would be done in a plug-in, 
separated from the library. In practice, the Checker would run a 
configuration that is not the mobileOK configuration. By definition, a 
global PASS outcome when the configuration is not the mobileOK 
configuration does not mean anything about the mobileOK-ness of the 
tested resource.

One minor point: the AbstractXSLTTestTimplementation class cannot be 
derived easily in plug-ins tests for the time being, because the class 
searches the styleseet in the xslt subfolder of the JAR.

Version number?
Given that many classes changed and that the new version is not backward 
compatible (in terms of classes, that is), I wonder how the new version 
shall be named: 1.1? 2.0?


[2] bug 6797: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6797
[3] bug 6798: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6798

[For tracking purpose, this is somewhat related to ACTION-916]
Received on Friday, 10 April 2009 14:07:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:20 UTC