RE: Various moki related

Hi Sean...

> 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.

Screenshots from Notepad++ is what I am using to show XML code.

It was the best (fastest) way for me to enter coloured formatted XML
code (from Notepad++). What I say is that in future versions I'll try to
have formatted XML code with nice colors in text format and not a PNG
copied in the doc.

I was only meaning this O:-)

My concern is whether, for example, the aboutme element (which I think
that is important but might come in the next release of the checker) is
going to be included in the alpha version (now). If so, I'll have to
change all the moki samples in the doc.

Nacho



-----Mensaje original-----
De: Sean Owen [mailto:srowen@google.com] 
Enviado el: martes, 16 de octubre de 2007 19:31
Para: Ignacio Marin
CC: Jo Rabin; public-mobileok-checker@w3.org
Asunto: 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:44:29 UTC