- From: Francois Daoust <fd@w3.org>
- Date: Tue, 14 Apr 2009 16:20:18 +0200
- To: Yeliz Yesilada <yesilady@cs.man.ac.uk>
- CC: public-mobileok-checker <public-mobileok-checker@w3.org>
Thanks, Yes, I will be at the WWW2009 conference next week, so we can definitely meet there to talk about the Checker. Francois. Yeliz Yesilada wrote: > Hi Francois, > > Thanks so much for re-factoring the code. We really appreciate your > time. I will download the code and have a look. If I have any question, > I will let you know. > > Btw, will you be at the WWW2009 conference next week in Madrid? > > Yeliz. > > On 10 Apr 2009, at 15:07, Francois Daoust wrote: > >> 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 Tuesday, 14 April 2009 14:20:58 UTC