W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > October 2007

Re: Some thougths about mobileok checker

From: Sean Owen <srowen@google.com>
Date: Mon, 15 Oct 2007 10:50:26 -0400
Message-ID: <e920a71c0710150750vb3c1bbdl9fa9df1ce30382a9@mail.gmail.com>
To: "Guido García Bernardo" <ggarciab@itdeusto.com>
Cc: public-mobileok-checker@w3.org
On 10/15/07, Guido García Bernardo <ggarciab@itdeusto.com> wrote:
> 1. Request headers
>
> I think support for overriding those headers not defined by mobileOK
> Basic will be very useful, not only to extend it, but for other purposes
> like validating if a website is mobileOk in different languages...

Seems reasonable -- I can add this.

>
> 2. Package-visibility
>
> A lot of methods are only visible from classes in the package
> org.w3c.mwi.mobileok.basic
> That makes it hard to reuse classes from third party developments (like
> mine :)

In general I'm reluctant to open up classes and methods to public
access that don't need to be public. The code was not necessarily
written to be extended at the code level, since it defines a specific
behavior of tests and should not need to be changed regularly by third
parties. One can use the "moki" XML output of the Tester, which
contains all information about the document, and build another
application on top of that.

Of course you can always hack up the code however you like for a
separate project, since it's open source.

That said, i suppose I am not that opposed to opening up some of the
utility method code if it really helps.


> 3. Maybe all AbstractTestImplementation classes should be moved to a new
> package "org.w3c.mwi.mobileok.basic.tests", to improve the code
> understandability to new arrived developers :)

Yes, the package is getting large. On the other hand, it lets us use
package-private access for most elements of the code, and only expose
publicly what should be called outside the package. I generally like
this since developers will not come to depend on details of the
implementation in ways that are not expected.


> 4. Not sure about this, but in the class HTTPResource you could use a
> MultiThreadedHttpConnectionManager

Agreed, I actually saw this and changed it over the weekend.

> 5. The class HTTPRedirect uses the getResponseBody method, that may
> result on java.lang.OutOfMemoryError exceptions. This is important when
> the code follows a link to a big resource (like a PDF file...).
> Not sure about if this is important in mobileOk tests.  Right now I have
> added a list of Content-Types that I do not want to follow, like
> "application/pdf".

I agree, this should probably be based on the size of the returned
document. I would suggest not saving documents in the moki document
that are over, say, 10KB. I can work on this.

Thanks very much Guido, this is helpful feedback. I have been
committing several more changes in the last few days which may improve
the speed as well. I am open to more thoughts on the points above;
these are just my initial reactions.

Sean
Received on Monday, 15 October 2007 14:50:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:04 GMT