RE: Various moki related

> -----Original Message-----
> From: Sean Owen [mailto:srowen@google.com]
> Sent: 16 October 2007 18:31
> To: Ignacio Marin
> Cc: Jo Rabin; public-mobileok-checker@w3.org
> Subject: Re: Various moki related
> 
> Do we need screenshots of something? I wouldn't imagine these would be
> necessary, or that these would need doc changes. No I think we should
> get a "good enough" draft of the doc today if possible so as to cut a
> release as soon as the last bugs are fixed. Some tests are still
> failing.

Don't propose to do anything except the minimum. Which is adding date
and version of the checker, I think. How do we set and determine the
version of the checker?

Screen shots - they illustrate the moki format, right? Think we use some
open source syntax highlighter, which might save on bulk of finished
doc.

> 
> I don't mind suppressing request headers, though I did just add a
> change that lets the caller change headers. I can see it being
> necessary in some situations (though altering the headers the tests
> specifies should make the results "unofficial"). Therefore I don't
> mind recording the exact request headers so much.
> 
Yes, that makes sense. But I guess that the headers don't change between
requests, though they may in some future version, I suppose.

> What is the "Connection" issue?

The issue is that HTTP requests typically share an underlying
connection. The fact that HTTP in RDF makes a record of this "inspired"
the idea that we should do the same. Not a big deal as far as I am
concerned and not one for alpha. Moki should make offer the opportunity
to record this, but doubt we will use it.

> 
> Raw headers are well raw. The "cooked" headers are sorted
> alphabetically, which may explain the difference you see.

Minor quibble but don't think they should really be sorted according to
my latest visits to RFC2616. But doesn't matter terribly, either,
afaics.

> 
> The body of the response is kept I believe only for the primary doc.
> I'd like to avoid adding, say, 100KB of base64-encoded images to the
> moki. (That said I did just add a "safety" that will prevent download
> of anything over 50KB.) But I can see an argument for at least
> including textual resources like CSS and javascript. I am happy with
> the current behavior though.

Yes it makes sense to keep the CSS. I guess I have a  minor qualm about
not having a copy of the processed CSS as well, but that is not an alpha
issue either, I guess. 

> 
> On 10/16/07, Ignacio Marin <ignacio.marin@fundacionctic.org> wrote:
> >
> > +1 to all.
> >
> > Shall I wait for changes in the code and then change the description
of
> > moki and the screenshots in user manual?
> >
> > One thing that I'd like to change in future versions is avoid
> > screenshots as much as possible and insert cool formatted text but
now
> > Notepad++ screenshots are a faster tool for me.
> >
> > Looking forward to news from you about these changes in the doc...
> >
> > Regards,
> >
> > Nacho
> >
> >
> > -----Mensaje original-----
> > De: public-mobileok-checker-request@w3.org
> > [mailto:public-mobileok-checker-request@w3.org] En nombre de Jo
Rabin
> > Enviado el: martes, 16 de octubre de 2007 19:12
> > Para: public-mobileok-checker@w3.org
> > Asunto: Various moki related
> >
> >
> >
> > Some things that may be worth fixing prior to alpha, which I will
do,
> > given that we agree what needs doing. Otherwise I'll raise bugs and
get
> > on with them for post alpha. Having done the moki XSD.
> >
> > 1. aboutme element
> >
> > This is missing at the moment - I think that for an alpha we could
miss
> > out on the library versions, but think we should have at a mimimum
> >
> > a. An overall version number
> > b. The time and date of the check
> >
> > [and the URI tested and the date and time really need to be in the
> > result document, no?]
> >
> > 2. RawHeaders element
> >
> > The time for this is probably passed now. I proposed to insert a
> > configuration option to suppress this, default true.
> >
> > That said, the headers don't always tie up exactly and are not
always in
> > the right order which I will briefly check.
> >
> > There's supposed to be a size attribute. Given the fact that the
> > rawheaders don't seem to be quite right at the moment this is of
limited
> > value, but the size should contribute to the overall size, methinks?
> >
> > 3. entity element
> >
> > Need to keep size, but ditto on the actual content of the element.
> >
> > 4. Connection stuff
> >
> > We haven't got this and wonder if we ever will. Not one for Alpha
> > anyway.
> >
> > 5. Request Headers
> >
> > An optimization would be to have a single copy, since (for now) they
are
> > invariant. Not one for Alpha
> >
> >
> >
> >
> >
> >
> >
> >
> >

Received on Tuesday, 16 October 2007 18:40:18 UTC