[PATCH 12 of 20] hgweb, paper: add shortlogajax template and use it

[Laurens Holst]

Op 14-08-13 22:31, Matt Mackall schreef:
> On Tue, 2013-08-13 at 23:24 -0500, Kevin Bullock wrote:
>> On 13 Aug 2013, at 3:44 AM, Alexander Plavin wrote:
>>
>>> 13.08.2013, 12:30, "Martin Geisler" <martin at geisler.net>:
>>>> Another thought that occured to me when I read the discussion about
>>>> writing an XML style: have you considered writing a JSON style instead?
>>>> That might be even more useful for JavaScript code.
>>> In this application (I mean infinite scrolling) json style doesn't give any differences/benefits to xml one, as we would have to render the templates in JS anyway. The only difference for future uses in javascript is using xfr.responsexml vs json.parse(xfr.responsetext). So, this variants are about equivalent and one of them just has to be chosen.
>>> However, I don't know what will be best here, and would like to hear more opinions on this.
>> I'd lean towards JSON as well. There are solid, widely-available
>> parsers for both, but JSON is generally more compact, and more widely
>> used by newer client-side libraries.
> Note that both JSON and XML have a serious problem that will need to be
> addressed before we can use them: can't pass arbitrary character sets.

JSON specifies that the encoding must be a form of Unicode [1].

XML does not mandate a specific encoding, although it does specify that 
if such encoding is not UTF-8 and there is no external encoding 
information, it must have an <?xml encoding?> declaration [2].

Then, I presume you can specify the encoding as:

     <?xml encoding=" unknown-8bit"?>

This is an IANA-registered encoding that's afaik also used by patchbomb.

So that would be a solid reason to favour XML over JSON.

When delivered over HTTP for hgweb consumption (as is the case here), I 
would pass the encoding specified in web.encoding in the Content-Type 
header. Content-Type overrides any encoding specified in the document 
itself, so you don't need to remove the above mentioned encoding 
declaration from the document.

~Laurens

[1] http://tools.ietf.org/html/rfc4627#section-3
[2] http://www.w3.org/TR/REC-xml/#charencoding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130820/2a03b8b6/attachment.html>