- From: Francois Daoust <fd@w3.org>
- Date: Fri, 20 Mar 2009 11:04:45 +0100
- 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. 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:05:21 UTC