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.

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.

What is the "Connection" issue?

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

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.

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 17:30:55 UTC