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

Hi Francois,

That sounds great. What is the time-line you have in mind to complete  
these changes?

Regards,
Yeliz.
On 20 Mar 2009, at 10:04, Francois Daoust wrote:

> 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.
>
> Francois.
>
>
> 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
>>> XSLT
>>>   - 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:40:24 UTC