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

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 09:13:35 UTC