- From: Francois Daoust <fd@w3.org>
- Date: Fri, 10 Apr 2009 16:07:20 +0200
- To: public-mobileok-checker <public-mobileok-checker@w3.org>
Hi, 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: http://dev.w3.org/2007/mobileok-ref/docs/org/w3c/mwi/mobileok/basic/package-summary.html#package_description TesterConfiguration ----- 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. Multi-threading ----- 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: http://dev.w3.org/2007/mobileok-ref/docs/org/w3c/mwi/mobileok/basic/package-summary.html#package_description 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? Thanks, Francois. [1] http://lists.w3.org/Archives/Public/public-mobileok-checker/2009Mar/0010.html [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