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

Re: mobileOK Checker library overhaul: changes committed

From: Yeliz Yesilada <yesilady@cs.man.ac.uk>
Date: Tue, 14 Apr 2009 15:10:35 +0100
Message-Id: <CFF83C3F-F39A-422E-9C58-1407EA34605C@cs.man.ac.uk>
Cc: public-mobileok-checker <public-mobileok-checker@w3.org>
To: Francois Daoust <fd@w3.org>
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:11:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 14 April 2009 14:11:15 GMT