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

Re: Handling the "file" scheme while preserving a clean reference implementation

From: Francois Daoust <fd@w3.org>
Date: Fri, 20 Mar 2009 11:04:45 +0100
Message-ID: <49C36A3D.7020607@w3.org>
To: Jo Rabin <jrabin@mtld.mobi>
CC: public-mobileok-checker <public-mobileok-checker@w3.org>
Actually, I think (hope?) it's more about code refactoring than real 
changes in the code, but that still requires a bit of work and testing.

I'd be happy to take the lead on implementing these changes.


Jo Rabin wrote:
> Hey, thanks Francois. That seems like quite a lot of work, plus some serious regression testing on the base classes to make sure they haven't been messed up.
> I have no objection to this being done. If it is to be done are you willing to act as the build-meister?
> Jo
>> -----Original Message-----
>> From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
>> checker-request@w3.org] On Behalf Of Francois Daoust
>> Sent: 19 March 2009 17:01
>> To: public-mobileok-checker
>> Subject: Handling the "file" scheme while preserving a clean reference
>> implementation
>> Hi guys,
>> Context
>> -----
>> I took ACTION-916 last week to identify the changes that would be
>> required to keep a clean mobileOK Checker library while still making it
>> possible to extend it using a restricted set of subclasses to add
>> support for the "file" scheme. Here are a few thoughts. What do you
>> think?
>> In short
>> -----
>> - It is possible, neither hard nor trivial.
>> - It cannot be backward compatible (e.g. some class names need to be
>> changed to do it properly), but would require limited updates from
>> external projects that may already use the library
>> - It would come with the added benefits that the library could be truly
>> used as a generic checking library on URIs, with a default mobileOK
>> profile that does just what it's supposed to do.
>> Why changes are needed
>> -----
>> The mobileOK Checker Java library is to remain a reference
>> implementation of the mobileOK Basic Tests 1.0 specification. As such,
>> introducing new test outcomes, new tests and/or new ways of retrieving
>> resources should not be part of it. It should be implemented as an
>> optional plugin.
>> The library was already implemented with extensibility in mind, but not
>> to the point that a mere derivation of a couple of classes is enough to
>> build on top of the reference implementation.
>> For instance, adding/completing/removing a test to the list of tests
>> run
>> by the checker cannot be done without modifying the list in the
>> TestType.java file. This should be doable without having to modify a
>> single line of code in the library, simply by plugging new classes.
>> The library was also designed with the mobileOK spec in mind, and is
>> sometimes correctly but unnecessarily restricted to the HTTP/HTTPS
>> schemes
>> Flexibility in the list of schemes supported
>> -----
>> The main thing to do, IMHO, is to separate the representation of a
>> resource from the way it is retrieved.
>> We currently have:
>>   HTTPResource
>>    |_ HTTPImageResource
>>    |_ HTTPObjectResource
>>    |_ HTTPTextResource
>>      |_ HTTPCSSResource
>>      |_ HTTPXHTMLResource
>>   HTTPResourceComparator
>>   HTTPRedirect
>> I suggest we drop the "HTTP" prefix in the above class names, use them
>> to store the representation of the resource and move the code used to
>> retrieve the resource to some derivative of a new ResourceRetriever
>> class. This would lead to:
>>   Resource
>>     |_ ImageResource
>>     |_ ObjectResource
>>     |_ TextResource
>>       |_ CSSResource
>>       |_ XHTMLResource
>>   ResourceComparator
>>   RetrievalElement (was HTTPRedirect)
>>     |_ HttpRetrievalElement
>>     |_ HttpsRetrievalElement (not sure we need to make a distinction)
>>     |_ FileRetrievalElement
>>     |_ ... (think "ftp" or whatever)
>>   ResourceRetriever
>>     |_ HttpResourceRetriever
>>     |_ HttpsResourceRetriever (not sure we need to make a distinction)
>>     |_ FileResourceRetriever
>>     |_ ... (think "ftp" or whatever)
>> Flexibility in the moki representation
>> -----
>> The HTTPRequest/HTTPResponse elements in the moki representation take
>> for granted that resources are HTTP/HTTPS resources. We may either live
>> with that and fill out the parts that can be filled when a file is
>> retrieved, update the schema for a more generic one. The clean solution
>> is indeed to re-engineer these sections in a more generic way.
>> Nothing too complicated, but it means updating XPath expressions in
>> almost all the tests.
>> In the code, it means the output of this section should be handled by
>> the corresponding resource class (i.e.
>> PreprocessorResults->addRetrievalElement should call a similar method
>> on
>> HttpRetrievalElement, FileRetrievalElement, ...)
>> I would do the changes for HTTP/HTTPS representations at the end, so
>> that we may use the existing test suite without any modification to
>> validate all the other changes before updating the moki results.
>> Flexibility in the enumerations
>> -----
>> It is not possible to extend an enumeration in Java. We need to switch
>> our enum declarations to some class implementation of an extensible
>> enumeration (a quick search reveals as many ways to do it as there are
>> developers around, it just cannot be as simple as a mere enum), so that
>> someone may derive TestOutcome for instance and add a CANNOTTELL test
>> outcome.
>> The other enumerations that needs to be re-written are:
>> - TestType to be able to change the list of tests being run, and/or
>> provide modified versions of the tests.
>> - HTTPErrorsType (I would drop the "HTTP" prefix as well), to add
>> errors
>> that are specific to the resource scheme.
>> Notion of profile
>> -----
>> The mobileOK profile could then be defined as:
>>   - the list of tests and implementations of the tests defined in the
>> library
>>   - a restriction to the HTTP/HTTPS schemes where retrieval is to be
>> made using a specific User-Agent, Accept, Accept-Charset.
>> I can think of various ways to define such a profile, one of them could
>> be simply to complete the existing TesterConfiguration class.
>> Minor other changes
>> -----
>> A few minor other changes are probably required.
>> Adding file scheme support
>> -----
>> Once the above is done (sic!), adding file support could be done easily
>> by implementing:
>>   - the FileResourceRetriever class
>>   - the FileRetrievalElement class
>>   - a derived TestOutcome class that adds the CANNOTTELL outcome
>>   - derived classes for tests that need to be amended and associated
>>   - a new profile that allows the file scheme and associate the tests
>> with the derived classes.
>> ... and that should not require any change in the core library.
>> Did I forget something that would make all of the above complete
>> non-sense? Is it unclear?
>> Francois.
Received on Friday, 20 March 2009 10:05:21 UTC

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