- From: Francois Daoust <fd@w3.org>
- Date: Fri, 20 Mar 2009 18:27:52 +0100
- To: Yeliz Yesilada <yesilady@cs.man.ac.uk>
- CC: Jo Rabin <jrabin@mtld.mobi>, public-mobileok-checker <public-mobileok-checker@w3.org>
Well, I have been proven invariably wrong in the past when it comes to providing time-lines. I'll try to stick to "things moving slow" approach to compute the time-line, but I'm not entirely sure the following can be regarded as correct. I'd say that a few days of work are enough to implement most of the changes. Then there needs to be a short discussion as to how the moki representation could be made more generic, and another couple of days to implement and check the changes. I think I should be able to find some time to work on the Checker after the F2F next week, so I would say we'd be done mid-April (without the file support implementation itself, but it would be far straightforward to implement after that), and sooner if all goes as planned. Does that look reasonable? Francois. Yeliz Yesilada wrote: > 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 17:28:29 UTC