[Kss-devel] Server response format

[Balazs Ree]

Sat, 12 May 2007 17:29:07 +0200 keltezéssel Jeroen Vloothuis azt írta:
> Like I said earlier I think the approach is flawed from the start. There
> is no reason I can think of to alter the structure of the response
> document. What I mean by this is that all data should be escaped and not
> made part of the DOM.

Could be escaped but exactly as you say it would not be part of the dom 
any more. It would become a parameter that we'd need to parse manually 
from the client into dom, The current format makes sure that is is parsed 
immediately when the browser recieves it.

> So the earlier example would like like:
> 
> ...
> <kukit:param name="html">
>      &lt;h1&gt;it worked
> </kukit:param>
> ..
>

I tried to explain this to you in irc. This would be wrong, because 
instead of the structured html you become a simple text node, but the 
content is not even a string as we know various things happen with non-
ascii character like enter. You could do this:

<kukit:param name="html" value="<h1>it worked</h1>" />

and then in the attribute you'd use the escaping you need inside 
attributes (which is btw not the same that you need in the html code).

Would this be better? I rather like to read an xml document then a string 
of two pages that contains an encoded structure, but indeed we can start 
thinking of this.

But, imo, put it in any way, it's the issuer's responsibility to issue 
valid html code. If invalid html is issues, the result will be broken at 
some point and you can't do anything against it (besides an attempt to 
same fix it as we currently do with beautifulsoup) So if your concern is 
this, I am afraid there is not much to do.

> This would make it possible to write a schema for the KSS reponse and
> validate it against that shema. If you allow arbitrary data this will
> not be possible.

Indeed this is true, no strict parsing is possible. I would add that even 
if we had dtd it would be no use at all, since the only ones that reads 
this are the clients that parse this xml with the builtin xmlhttprequest 
code, and they don't care for dtd. Even if you have a schema it would be 
useless.

> At the moment I do not see why escaping should not be default way. All
> actions that need DOM force any string anyway (for use with client side
> actions).

If it were in parameters, it'd need escaping. If it is in the body of the 
html, then it is valid html and not a string: so no escaping desired: 
tags need to be real tags.

> I would rather not duplicate the current behaviour (at least not until I
> understand why it is done this way) in the new kss.commands package. So
> please enlighten me on the design choices so that I may understand them.

The question is not the design choices at this point. This format 
developped in an evolutionary way that it should be simple to parse, 
handle on the client, and that it works cross browser. The question is 
what reason we have to change it right now. Some of your reasons may be 
valid, so we may return to this topic later, but let's not turn the 
"enable kss from pure python" story to a "change the commands transport" 
saga.

-- 
Balazs Ree