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

RE: CachingTest HTTP header re-request

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 26 Jun 2007 15:51:17 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B43BC708@mtldsvr01.DotMobi.local>
To: "Sean Owen" <srowen@google.com>, Roland Gülle <roland@7val.com>
Cc: "Laura Holmes" <holmes@google.com>, <public-mobileok-checker@w3.org>

I remain sceptical that this aspect of the caching tests should actually be in mobileOK at all - and would prefer that we removed it than run around the houses in this way, since it doesn't tell us anything specifically mobile.

Jo

> -----Original Message-----
> From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> checker-request@w3.org] On Behalf Of Sean Owen
> Sent: 26 June 2007 15:47
> To: Roland Gülle
> Cc: Laura Holmes; public-mobileok-checker@w3.org
> Subject: Re: CachingTest HTTP header re-request
> 
> I don't think it makes sense to do these re-requests in the
> preprocessing phase, since it's only needed in some cases, and doesn't
> meaningfully contribute to uses of the intermediate document outside
> mobileOK Basic. I think it's pushing this approach a notch too far and
> bloats the intermediate doc. In any event that part of the moki doc
> hasn't been implemented by anyone yet, so I'd suggest we use Java in
> exactly cases like this.
> 
> On 6/26/07, Roland Gülle <roland@7val.com> wrote:
> >
> > Hi Laura,
> >
> > > Is anyone attached to this implementation for any specific reason?
> > > And if so, can you explain to me the logic behind the request being
> > > implemented prior to this comparison?
> > Im attatched:
> > http://docs.google.com/View?docID=w.dgh5r6zs_5cb7gz3&revision=_latest
> > but not for specific reason - if you want to attach, go for it!
> >
> > Actually there is no re-request in the XSLT implemented.
> > The XPath:
> > <xsl:if test="ancestor::HTTPResponse[1]/following-
> > sibling::HTTPResponse[1]
> >                       and
> >                       not(ancestor::HTTPResponse[1]/following-
> > sibling::HTTPResponse[1]/status[@code = '304'])">
> > checks the result of the re-request in the moki document, so the
> > current implementation needs the 'intelligence' to handle re-request
> > in the moki document generator.
> >
> > The question to all:
> > Should be this handled in the moki document generator or should the
> > XSLT call java code when this is needed?
> >
> > Cheers,
> >   Roland
> >
> >
> >
Received on Tuesday, 26 June 2007 14:51:41 GMT

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