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 Thursday, 19 March 2009 17:01:37 UTC