| 00:17 | <Lachy> | othermaciej, the links to the decisions for issues 120 and 142 are linking to the wrong post. Can you fix this? http://dev.w3.org/html5/status/formal-objection-status.html |
| 00:17 | <othermaciej> | Lachy: yes |
| 01:34 | <othermaciej> | Lachy: fixed |
| 03:34 | <DJTrey> | any reason why this isn't playing in firefox 3.6.0 |
| 03:34 | <DJTrey> | http://pastebin.com/V8ncecLy |
| 04:04 | <doublec> | DJTrey: what's it do? Does it show the element at all? |
| 04:04 | <DJTrey> | nevermind. i got it |
| 04:04 | <DJTrey> | i moved around some things and it started working.... |
| 04:04 | <DJTrey> | might've been the AddType too |
| 04:04 | <doublec> | my first thought would have been the server not sending the correct mime type |
| 08:53 | <hsivonen> | is it known who Harald Alvestrand is consulting for in the p2p API case? or is he doing it on his own dime and time? |
| 09:23 | <doublec> | hsivonen: wikipedia says he works for the big G |
| 09:23 | <hsivonen> | doublec: interesting |
| 09:25 | <doublec> | should I be saddened that W3C keeps membership passwords in clear text |
| 09:26 | <jgraham> | I am |
| 09:26 | <hsivonen> | doublec: yes. at W3C meetings, as a tinfoil hat, I route my traffic through Mountain View |
| 09:26 | <doublec> | I'm glad I picked one so hard to guess I couldn't even remember it and wrote it down wrong |
| 09:26 | <doublec> | (I'm referring to their password reset stuff which sends the password out in email) |
| 09:27 | <doublec> | but I guess they're using basic auth too |
| 09:27 | <hsivonen> | (not to suggest that anyone in particular would sniff my password at a meeting, but at those meetings, there a plenty of people *capable* of sniffing around and there's a need to send the password over wifi) |
| 09:28 | <doublec> | yeah, tunnelling the traffic is a wise move |
| 09:30 | <hsivonen> | jgraham: I think it's sad that the Chairs labeled your RDFa findings as "arguments not considered" even though they did accept the claims about existing usage |
| 09:32 | <jgraham> | hsivonen: I am somewhat considering raising an objection on the basis that the chairs failed to properly consider the arguments presented. However I am interested to see their response to my enquiry about what was considered first |
| 09:33 | <hsivonen> | jgraham: Sam's reply to Tab hints that if you do, you need to use sudo |
| 09:33 | <hsivonen> | jgraham: i.e. make it Formal |
| 09:33 | <jgraham> | Yes, I understand that the word objection is considered meaningless without the word Formal |
| 09:34 | <hsivonen> | at least JF not only uses Formal but FORMAL |
| 09:35 | <jgraham> | So far I am disappointed that neither sicking nor I have got responses to our request for more information about recent decisions |
| 09:39 | <hsivonen> | oh, nice. Tab already made his points Formal. |
| 09:40 | <hsivonen> | I wonder if it makes any difference if I make the same points Formally as well |
| 09:43 | zcorpan | recalls FORMAL COMPLAINT |
| 09:44 | <jgraham> | I am somewhat hesitant to recommend a course of action that will undoubtedly lead to multiple Formal objections for each issue that fails to adopt a change proposal from the a11y people |
| 09:44 | <jgraham> | But I have no idea what the process for considering these objections is |
| 09:45 | <hsivonen> | I find it amusing that karlcow relays a Japanese requirement never to have subtitles for two movie characters on screen at the same time when translating Japanese to English in the anime context supposedly require all sorts of clutter |
| 10:38 | <hsivonen> | Hooray! UTF-7 and UTF-32 removed from Gecko trunk! |
| 10:41 | <zcorpan> | yay |
| 10:41 | <zcorpan> | isn't utf-7 needed for email in thunderbird? |
| 10:44 | <hsivonen> | zcorpan: IIRC, there was a solution that enabled email decoding without exposing UTF-7 as a general-purpose decoder |
| 10:44 | <hsivonen> | zcorpan: IIRC, email decoding in Thunderbird doesn't have the architecture one would expect anyway |
| 10:46 | <hsivonen> | zcorpan: did you see http://www.w3.org/Bugs/Public/show_bug.cgi?id=12398 ? |
| 10:48 | <zcorpan> | hadn't seen that |
| 10:51 | <zcorpan> | agree with wontfix |
| 10:52 | <hsivonen> | zcorpan: might be worthwhile to say that on the bug |
| 10:54 | <jgraham> | +1 |
| 10:57 | <jgraham> | Live dom viewer down :( |
| 11:06 | <hsivonen> | zcorpan: thanks for the bug comment |
| 11:06 | <zcorpan> | np |
| 11:08 | hsivonen | wonders how much usage share Firefox 4 and Chrome need to get in Germany before http://www.mypokito.de/ gets fixed |
| 11:09 | <roc> | hsivonen: removed UTF-7 and UTF-32 just now? I don't see it |
| 11:12 | <hsivonen> | roc: https://bugzilla.mozilla.org/show_bug.cgi?id=604317 https://bugzilla.mozilla.org/show_bug.cgi?id=414064 |
| 11:14 | <roc> | oh right |
| 11:14 | <roc> | thanks |
| 11:54 | <karlcow> | hsivonen: re japanese subtitles - And I didn't talk about the characters kerning etc. It's impressive how strict they are. But I have heard a lot of these specific requirements for the last year or two at a regular pace at home in the evening ;) |
| 11:58 | <MikeSmith> | karlcow: the subtitles I see in Japanese films don't seem to me to have much sophisticated typography requirements at all |
| 13:24 | <hsivonen> | karlcow: I thought Japanese typography didn't need kerning because all glyphs are equally wide |
| 13:24 | <hsivonen> | What part of Firefox reporting Gruber highlights is so predictable: http://daringfireball.net/linked/2011/03/29/firefox-mobile-flash |
| 13:28 | <karlcow> | hsivonen: in fact they do need kerning. I'll find you a reference. |
| 13:29 | <karlcow> | TSUMEGUMI (kerning / tracking) |
| 13:30 | <karlcow> | http://www.w3.org/TR/2008/WD-jlreq-20080411/#subheading1_2_3 |
| 13:30 | <karlcow> | Adjustment of inter-character space by making the distance between the letter face of adjacent characters shorter than that produced by solid setting. (JIS Z 8125) |
| 13:31 | <karlcow> | better http://www.w3.org/TR/jlreq/#en-subheading1_2_3 |
| 13:32 | <erlehmann> | hsivonen, is there any value in reading grubers ramblings except for the occasional chuckle? |
| 13:33 | <erlehmann> | i mean, if you are not that into apple culture. |
| 13:33 | <erlehmann> | (which i am, decidedly, not) |
| 14:36 | <hsivonen> | This is a curious case https://bugzilla.mozilla.org/show_bug.cgi?id=646224 |
| 14:36 | <hsivonen> | why does the page look "right" in Safari 5? |
| 14:39 | <jgraham> | Safari 5 has the old parser, right? |
| 14:40 | <hsivonen> | jgraham: yes |
| 14:41 | <hsivonen> | jgraham: so why doesn't the spec clone any of old Gecko, old Trident or old WebKit in this case? |
| 14:42 | <hsivonen> | is this due to the AAA difference between old WebKit and the spec? |
| 14:42 | <hsivonen> | the difference that I can neither pin down nor understand |
| 14:42 | <hsivonen> | but that Hixie says is a "fix" |
| 15:02 | <karlcow> | hsivonen: the new UI of Skype really sucks on the mac at least. A lot bigger, too many things. |
| 15:03 | <hsivonen> | karlcow: OK. I wonder if the old one has known vulnerabilities. I haven't upgraded. |
| 15:04 | <karlcow> | I reverted myself to the old one when I tried the beta |
| 15:05 | <karlcow> | I think the new UI is in HTML |
| 15:07 | <Rik`> | so HTML is worse than native apps, q.e.d. ! :) |
| 15:08 | <moo-_-> | HTML is the new native |
| 15:08 | <karlcow> | heh for certain things such as UI ;) I had written something along this a long time ago. On how I was wishing that instead of putting all apps in my browser, I wanted to have the Web in my apps. Aka using HTTP and api, etc |
| 15:09 | jgraham | doesn't hate new skype as much as he had been led to believe he might |
| 15:10 | <karlcow> | jgraham: I tried to use it for… 2 weeks then reverted. |
| 15:10 | <jgraham> | Ah, I think I tried once so far |
| 15:27 | <zcorpan> | hsivonen: safari doesn't match the spec for <a><div></a> either |
| 15:28 | <zcorpan> | or <b><div></b> |
| 15:28 | <zcorpan> | seems like a spec bug |
| 15:38 | <zewt> | karlcow: heh, i'm using a windows skype client from a couple years ago--anything newer i find utterly unusable |
| 15:55 | <mooreinteractive> | navigation.getUserMedia anyone know about this? |
| 17:39 | <nimbupani> | hey everyone, I am trying to "guess" the default line-height that all browsers use, but it seems pretty random, does anyone know if there is any documentation other than the spec (which sez it should be between 1.0 and 1.2) http://jsfiddle.net/nimbu/rg8FX/ |
| 18:15 | <kennyluck> | http://krijnhoetmer.nl/irc-logs/css/20110330#l-395 |
| 18:15 | <MikeSmith> | zcorpan: you'll be able to have the html-diffs document updated for April 5 WD publication? |
| 18:23 | <zcorpan> | yep |
| 18:23 | <MikeSmith> | thanks |
| 18:38 | <karlcow> | http://twitter.com/mnot/status/53128146882543616 |
| 18:38 | <karlcow> | >"This group primarily conducts its technical work on a Public mailing list public-html." #bullshit #w3c |
| 18:39 | <karlcow> | I'm wondering to which specific event mnot is reacting to |
| 18:39 | <kennyluck> | Me too. |
| 18:40 | <kennyluck> | The sentence in the charter? |
| 18:40 | <Philip`> | I thought the group conducts its technical work on the whatwg list, and public-html is just for Process spam |
| 18:40 | <AryehGregor> | Be fair, some technical work is done on Bugzilla. |
| 18:41 | <kennyluck> | You need to define what "the group" means then. |
| 18:42 | <Philip`> | I mean the people who cause changes to occur in the HTML5 spec that the HTML WG publishes |
| 18:42 | <karlcow> | As usual, and like it has always been since its inception, technical work is done everywhere, in meetings, mailing-lists, private discussions, irc, companies bug trackers, etc. |
| 18:49 | <zcorpan> | MikeSmith: hey i fixed a bug! |
| 18:49 | <MikeSmith> | eh? |
| 18:49 | <MikeSmith> | which bug? |
| 18:49 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=10796 |
| 18:50 | <MikeSmith> | oh cool |
| 18:51 | <MikeSmith> | I think that's more bugs than Anne has fixed in the whole history of him maintaining that document! |
| 18:51 | <zcorpan> | lol |
| 18:51 | <MikeSmith> | so I think that means Anne will be very happy for you take over permanent ownership of it |
| 18:51 | <MikeSmith> | (which was probably his plan all along) :) |
| 18:51 | <zcorpan> | likely |
| 18:51 | <karlcow> | Anne is evil |
| 18:52 | <MikeSmith> | Anne is a god |
| 18:52 | <MikeSmith> | but like Loki |
| 18:52 | <karlcow> | well that's the same no? |
| 18:52 | <MikeSmith> | heh |
| 18:53 | <zcorpan> | hmm, should i say that xml:space is only allowed in XHTML documents? |
| 18:53 | karlcow | is reading Iliad these days ;) and really impatient to finish. Two chapters to go. I have blood all over my face. The body count starts to put me down |
| 18:53 | <MikeSmith> | the ways of Anne are precocious/unpredictable |
| 18:53 | <MikeSmith> | zcorpan: yeah, prolly |
| 19:12 | <MikeSmith> | zcorpan: "The dl now represents an association list…" should maybe better be, "The dl element now represents an association list…" |
| 19:15 | <zcorpan> | heh, thanks |
| 19:22 | jgraham | wonders if karlcow should put the book down and visit the hospital if he is covered in blood |
| 19:22 | <jgraham> | Or the police station, depending on whose blood it is |
| 19:24 | <karlcow> | jgraham: I'm counting on Apollon, Hera, Artemis, Zeus, etc. to help |
| 19:37 | <Hixie> | hsivonen: harald is a googler, strong ietf background |
| 19:38 | <smaug____> | AryehGregor: what you mean with "surroundContents() doesn't work |
| 19:38 | <smaug____> | here, because in all browsers except Opera it removes all children of |
| 19:38 | <smaug____> | the node before appending the range's contents. (Opera actually |
| 19:38 | <smaug____> | follows DOM 2 Range here, but other browsers don't.)" |
| 19:39 | <smaug____> | AryehGregor: all children should be removed from newParent |
| 19:40 | <AryehGregor> | smaug____, oh, I missed that part, sorry. |
| 19:40 | <AryehGregor> | You're right, it says "If the node newParent has any children, those children are removed before its insertion." |
| 19:40 | <AryehGregor> | That was at the end after it described the actual steps to take, so I missed it. |
| 19:41 | <AryehGregor> | My bad. |
| 19:41 | <smaug____> | DOM 2 Range is hard to read |
| 19:41 | <smaug____> | in general it seems to be internally consistent, but just hard to read |
| 19:41 | <AryehGregor> | Yeah. |
| 19:41 | <AryehGregor> | And vague. |
| 19:42 | <AryehGregor> | (although not *that* vague) |
| 19:42 | <AryehGregor> | (not like a lot of CSS specs, for instance, much clearer than that) |
| 19:42 | <smaug____> | yeah, not that vague, just hard to read |
| 19:49 | <zewt> | it's just way too descriptive, more like a paper describing the API than a spec |
| 19:50 | <zewt> | actually i'm not sure if i've looked at that particular one, i'm just thinking of ... well, every dom 2 spec I've ever looked at |
| 19:53 | <zewt> | that one's layout isn't as bad as some, anyway |
| 20:02 | <karlcow> | was the first ever user agent string Mosaic? http://webaim.org/blog/user-agent-string-history/ |
| 20:08 | <AryehGregor> | Okay, so this alerts "bar": data:text/html,<!doctype html><script>var a = "foo"; var f = function() { alert(a); }; a = "bar"; f();</script> |
| 20:09 | <AryehGregor> | Is there any way, when making f, to fix the values of all the variables it references, so that in this case it would alert "bar"? |
| 20:09 | AryehGregor | isn't sure this is the right approach to his problem at all |
| 20:09 | <AryehGregor> | I mean, I want a to be evaluated at function declaration time, not when the function is run. |
| 20:10 | <kennyluck> | OCaml does something like this IIRC. I don't think Javascript would allow you to do this. |
| 20:10 | <AryehGregor> | Hmm: data:text/html,<!doctype html><script>var a = "foo"; var f = function(a) { return function() { alert(a); } }(a); a = "bar"; f();</script> |
| 20:10 | <AryehGregor> | That works. |
| 20:10 | <AryehGregor> | Although it's kind of . . . um. |
| 20:11 | <AryehGregor> | Functional programming can get weird sometimes, amirite? |
| 20:14 | <AryehGregor> | So, that was an exciting hour exploring JavaScript. |
| 20:14 | <zewt> | use a different variable so you're not assigning over it later, heh |
| 20:15 | <zewt> | var a = "foo"; var b = a; var f = function() { alert(b); }; a = "bar"; f(); |
| 20:16 | <AryehGregor> | I'm doing this in a loop, any variable I use will get overwritten by the next iteration. |
| 20:17 | <AryehGregor> | Which is why I specified the question in terms of the function, not the variables. |
| 20:17 | <zewt> | var -> let? |
| 20:17 | <AryehGregor> | let? |
| 20:18 | AryehGregor | looks |
| 20:19 | <AryehGregor> | What's the actual difference between let and var? MDC is unhelpful (uncharacteristically). |
| 20:19 | <zewt> | http://zewt.org/~glenn/example.html |
| 20:19 | <AryehGregor> | Oh, I see. |
| 20:19 | <AryehGregor> | It gives you C-style variable binding semantics. |
| 20:19 | <zewt> | i've only seen its difference in code and not from docs, but from what I understand, var scopes to the function; let scopes to the block |
| 20:19 | <AryehGregor> | That'll do it, thanks. |
| 20:20 | <zewt> | also note that you usually need to explicitly set a javascript version |
| 20:20 | <zewt> | so watch out for older browsers |
| 20:20 | <jgraham> | let doesn't exist |
| 20:20 | <jgraham> | unless you only care about spidermonkey |
| 20:20 | <AryehGregor> | Oh. |
| 20:20 | <zewt> | function-wide scoping is so horribly broken |
| 20:20 | <AryehGregor> | Never mind, then. |
| 20:21 | <jgraham> | AryehGregor: I think your solution seems reasonable |
| 20:22 | <jgraham> | Although I am not really following |
| 20:26 | <AryehGregor> | I've come to suspect that my attempt to reduce code duplication has become horribly overengineered. |
| 20:27 | <AryehGregor> | Copy-paste starts to look attractive again. |
| 20:31 | <AryehGregor> | jgraham, I mean, you were the one who wrote the templating code in testharness.js, right? |
| 20:31 | <jgraham> | In testcases it is less evil than in normal code |
| 20:32 | <jgraham> | AryehGregor: yes... |
| 20:32 | <AryehGregor> | You mean copy-paste is less evil? Because it won't have to be maintained, yeah. |
| 20:32 | <jgraham> | right |
| 20:33 | <jgraham> | although it can be necessary to change tests |
| 20:37 | <MikeSmith> | jgraham: I am thinking about coming by Linköping before or after the W3C AC meeting in May |
| 20:38 | <MikeSmith> | to talk with you and others there about testing, test-harness stuff, etc |
| 20:38 | <MikeSmith> | if you think that would be a good use of time |
| 20:38 | <MikeSmith> | maybe we can get gsnedder1 to visit at that time |
| 20:40 | <MikeSmith> | it would be a major achievement if we could get agreement about a cross-WG test harness by end of this summer |
| 20:40 | <MikeSmith> | one that met everybody's needs |
| 20:48 | <jgraham> | MikeSmith: I approve of this plan |
| 20:48 | <jgraham> | I expect gsnedders is at university then |
| 20:50 | <aho> | anyone knows why there still isn't some source+target rect stuff in CSS? (i.e. the kind of thing you get with *every* 2d drawing API. it's almost as if the csswg pretends that sprites don't exist.) |
| 20:51 | <gsnedder1> | miketaylr: When exactly is that? |
| 20:51 | <aho> | e.g. x1 y1 w1 h1 x2 y2 w2 h2 :> |
| 20:51 | <gsnedder1> | MikeSmith, that was meant to be |
| 20:51 | <AryehGregor> | aho, there's a spec for that, just not implemented yet. |
| 20:51 | <AryehGregor> | Media fragments. |
| 20:51 | <AryehGregor> | Okay, so all my massive rewriting wound up being 124 insertions and 189 deletions, with a massive decrease in comprehensibility. I think I'm going to have to chuck it out. |
| 20:51 | <aho> | got a link? |
| 20:52 | <aho> | http://www.w3.org/2010/11/02-mediafrag-minutes.html <- this one? |
| 20:52 | <aho> | eh wait |
| 20:52 | <aho> | :> |
| 20:52 | <AryehGregor> | aho, http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ |
| 20:52 | <aho> | http://www.w3.org/TR/media-frags/ |
| 20:52 | <AryehGregor> | Yeah, that's the WD. Avoid those, they tend to be outdated. |
| 20:53 | <aho> | kay |
| 20:53 | <AryehGregor> | Hmm, but if I revert this, I'll have to redo the functional improvements I made . . . |
| 20:53 | <AryehGregor> | Oh well, I'll just add some comments and hopefully it will be fine. |
| 20:54 | <aho> | does that also include that svgView stuff (foo.svg#svgView(viewBox(0,200,1000,1000)))? |
| 20:54 | <AryehGregor> | I don't know, I haven't looked at it lately. |
| 20:54 | <AryehGregor> | Or ever read it very carefully. |
| 20:57 | <aho> | foo.png#xywh=160,120,320,240 |
| 20:57 | <aho> | mh. yea. that would work, i guess |
| 20:57 | <aho> | doesn't include scaling/flipping like source/target rect does though |
| 20:58 | <aho> | i'm also kinda disappointed that this stuff is buried in this huge heavy spec... it will probably take ages until it's implemented |
| 20:58 | <AryehGregor> | I dunno about that. |
| 20:58 | <AryehGregor> | Or if it will, it's not because of the spec size, it's because of what implementers think is important. |
| 20:59 | <aho> | well, sprites are just awful and everyone uses them anyways |
| 20:59 | <aho> | it's really surprising that there isn't a good solution available yet |
| 21:01 | <aho> | i mean, doing this kind of thing is easier and more manageable in generic programming languages |
| 21:01 | <zewt> | arguably scaling/flipping doesn't belong there, though |
| 21:02 | <zewt> | i've wished i could reference sprites within a PNG with a fragment like that before though |
| 21:02 | <aho> | we all did... ;) |
| 21:02 | <zewt> | (if you want to scale or resize--there's already CSS for that) |
| 21:02 | <zewt> | (er, scale, flip, etc) |
| 21:04 | <gsnedders> | From CSS WG telecon minutes: RESOLVED: Advance CSS2.1 to PR. |
| 21:04 | <aho> | test.jar!/img1.png |
| 21:04 | <aho> | works with firefox :> |
| 21:04 | <aho> | http://kaioa.com/b/0907/jartest.html |
| 21:05 | <aho> | url(jar:test.jar!/img2.png) <- different proto though |
| 21:06 | <zewt> | that helps some of the use cases of sprites ... not all though |
| 21:06 | <zewt> | does help the probably most common one, though (reducing network requests) |
| 21:07 | <aho> | ye, well zip is kinda silly for that anyways |
| 21:07 | <zewt> | zip is fine for that, really |
| 21:07 | <aho> | i just used it for that demo (article here: http://kaioa.com/node/99 ) because it worked in firefox |
| 21:07 | <zewt> | (as long as compression is disabled, of course) |
| 21:08 | <zewt> | not ideal for sprite animations, though |
| 21:08 | <AryehGregor> | gsnedders, that would be more interesting and impressive if they didn't leave so much stuff undefined and/or untested to reach that goal. |
| 21:08 | <aho> | zip isn't a solid archive (less efficient compression - however, files can be decompressed individually), support for utf-8 is poor, support for changing the order of the files is poor, it uses a *trailing* index |
| 21:09 | <aho> | it's a general purpose archive format. that trailing index makes sense in that case. i.e. if you add one or two files to that 2gb file, you won't have to rewrite the whole thing |
| 21:09 | <aho> | but if it's used as transport mechanism over the wire, a leading index would make much more sense |
| 21:09 | <zewt> | solid archives are bad for this sort of use |
| 21:10 | <aho> | you want to know what stuff is inside the archive as soon as possible |
| 21:10 | <zewt> | you don't want to have to decompress the entire file to randomly access one file inside it |
| 21:10 | <zewt> | (also, when you're packaging sprites you don't want compression anyway) |
| 21:10 | <aho> | you would decompress all of it either way |
| 21:10 | <aho> | and populate the cache with that stuff |
| 21:10 | <zewt> | i wouldn't, i'd decompress on demand |
| 21:11 | <aho> | you can inflate hudreds of mb per second on a cheap office machine |
| 21:11 | <aho> | decompressing some tiny file really isn't an issue |
| 21:11 | <aho> | deflate is really really cheap |
| 21:12 | <zewt> | decompressing files that you're never going to access? that's just wasteful and increases latency |
| 21:12 | <aho> | why would you put files into some RP which aren't used? |
| 21:13 | <zewt> | used rarely and not used at all are different things, eg. icons for submenus |
| 21:13 | <zewt> | the nice thing about zip is that it's the most widely-supported, well-understood archive format there is, which is no small thing |
| 21:14 | <zewt> | not that it's without some warts (zip64, grr) |
| 21:14 | <aho> | yeaaa... that's kinda misaligned though. what you actually want for this is a format which can be easily written with std libraries which are available everywhere |
| 21:14 | <jgraham> | AryehGregor: Be nice, it has taken the CSSWG a decade to get CSS2.1 this far :) |
| 21:15 | <aho> | this is true for zip, but it would be also true for a custom format with a leading header |
| 21:15 | <AryehGregor> | jgraham, where "this far" is an arbitrary and useless bureaucratic milestone instead of a measurement of anything useful. |
| 21:16 | <gsnedders> | AryehGregor: It's not just a bureaucratic milestone, REC has meanings beyond the bureaucratic (patent policy comes into affect, etc.) |
| 21:16 | <aho> | zewt, zip also doesn't support mime types |
| 21:17 | <zewt> | not a practical problem in my experience, just a would-be-nice |
| 21:17 | <AryehGregor> | gsnedders, fine, it's not a measurement of anything *technically* useful. The patent policy might be interesting to lawyers. |
| 21:18 | <zewt> | the universal support for ZIP just puts a very high bar in my mind for using something else |
| 21:19 | <jgraham> | gsnedders: If that is the metric of useful, then we should be worried that they overran by >= 6 years |
| 21:19 | <aho> | zewt, the trailing header is a practical problem though. the proposed "solution" is to put some index file into the archive first, which is kinda silly... just writing that index and the data (and piping it through zip) would be all we need |
| 21:19 | <aho> | *gzip |
| 21:20 | <aho> | amount of code on the server side would be also about the same |
| 21:20 | <aho> | there is nothing relevant to gain by using zip |
| 21:20 | <zewt> | nothing? i already have tools on every platform i use to manipulate zips; that's a huge win in and of itself |
| 21:21 | <zewt> | putting extra index files in archives is a terrible idea--then you have to use special tools to manipulate the zip (to keep the index up to date), which pretty much defeats all of the benefit |
| 21:23 | <zewt> | especially if using regular tools on them results in an inconsistent index file and causes confusing problems--at which point you're worse off than you'd have been with a new format |
| 21:23 | <jgraham> | gsnedders: (a more reasonable technical point would be that they finally got a useful testsuite together) |
| 21:23 | <jgraham> | gsnedders: (hopefully we do better in the future, although there is no assurance of that) |
| 21:24 | <aho> | if that custom format becomes some spec, there will be tools to support that format, too |
| 21:24 | <aho> | would require about 50 lines of java or so |
| 21:24 | <zewt> | java? |
| 21:24 | <zewt> | heh |
| 21:28 | <AryehGregor> | jgraham, is that the test suite that consists entirely of manual tests and which Microsoft takes three days to run? |
| 21:28 | <aho> | not really a big deal if it uses some standard compression scheme like deflate |
| 21:30 | <aho> | i used java as example for a somewhat verbose language which is used on the server side |
| 21:30 | <aho> | actually... i already do use some kind of custom format which is created on the server side |
| 21:31 | <aho> | it got a leading index, mime types, and the data is b64 encoded (for performance reasons) and the whole thing is gzipped |
| 21:31 | <zewt> | fwiw, another reason for a trailing index on zips is it makes it trivial to stream zips |
| 21:31 | <zewt> | not a critical property, just another handy one |
| 21:32 | <aho> | http://mbtic.com/games/dadadash/dadadash-ogg.ibz <- looks like this |
| 21:32 | <aho> | it's really not very difficult to create |
| 21:32 | <aho> | did it first with php and nowadays it's done with java |
| 21:33 | <aho> | it's some kind of mxhr thing, basically |
| 21:34 | <aho> | well, the point is... people already do use custom formats, because they have to :> |
| 21:36 | <zewt> | my point is, the bar should be set very high for using a custom format over a broadly-supported one; the bar is there and there are real cases when it's needed, but i err conservative on making up new file formats |
| 21:36 | <jgraham> | AryehGregor: There are certainly lessons to be learnt from it, yes |
| 21:36 | <aho> | tell me if you find one which was made for a similar use case |
| 21:37 | <zewt> | i definitely would say that adding hacks to ZIP like a leading index file is much worse than just making a new format, though. |
| 21:37 | <aho> | zip really isn't a sensible choice for this |
| 21:40 | <aho> | requirements: leading index, mime types, utf-8, deflate. ideally: seekable (i.e. it should be possible to decode a specific file inside that archieve without having to download everything. just the index and then the range which contains that file.) |
| 21:41 | <aho> | this would for example allow browser vendors to open parallel connections (if it appears to be worth it) and progressively load those files from the 2nd/3rd/4th connection without having to finish the block from the 1st connection first |
| 21:43 | <aho> | and seriously... writing something like that or a zip is about the same amount of code. it really isn't a big difference |
| 21:43 | <zewt> | it's not the same amount of code when you already have code and infrastructure to handle zips (as firefox already does, with jars) |
| 21:44 | <zewt> | personally i'm less interested in browser overhead ("not my problem" and not likely to be a sticking point in practice) as with toolset ("tools will support this eventually" isn't the same as "everything already does") |
| 21:45 | <aho> | that jar stuff is some ancient leftover code... it would require a complete rewrite for progressive loading etc |
| 21:45 | <zewt> | and a general aversion to format proliferation |
| 21:45 | <aho> | amount of code... meant on the server side |
| 21:46 | <aho> | i.e. code which needs to be written by the people who want to utilize RPs |
| 21:46 | <zewt> | i already have code to generate zips in my website architecture :) |
| 21:47 | <aho> | well, spitting out some simple header and gzipping the whole lot won't look much different |
| 21:47 | <zewt> | well, this format is inherently different--you need to have the data already compressed before you can output a header, since presumably the header would include indexes to each file |
| 21:48 | <aho> | ideally, yes |
| 21:49 | <aho> | (i.e. if you /also/ want that seekability) |
| 21:49 | <aho> | (not "just" a leading header) |
| 21:49 | <zewt> | well, you get that with zips |
| 21:50 | <aho> | zips got a trailing header |
| 21:50 | <zewt> | yes but you do get file offsets |
| 21:50 | <aho> | and each file also got its own header |
| 21:50 | <aho> | so you have to download the whole thing in order to be able to tell which files it contains |
| 21:50 | <zewt> | file-local headers in zips mostly don't matter (they're redundant with the trailing header) |
| 21:51 | <zewt> | no, you only need to download the end of the file to get the index--it's just more round-trips to do so |
| 21:51 | <zewt> | which for this sort of use you presumably want to minimize |
| 21:52 | <aho> | yea... i mean, that's the big idea, isn't it? ;) |
| 21:52 | <zewt> | it would typically take two extra round-trips to download the central directory in advance |
| 21:53 | <zewt> | though, that would also make caching more complex |
| 21:54 | <aho> | "you need to have the data already compressed" <- this isn't a big deal, by the way. it's an AOT operation and the amount of data is fairly small. you can do all of that in-memory and once you got everything you need you write it in one go |
| 21:54 | <zewt> | eg. using ETag or something to make sure that the end of central directory, central directory and then files are all from the same file |
| 21:54 | <zewt> | which is just annoying and easy to get wrong |
| 21:55 | <zewt> | that depends on what you're putting in the archive |
| 21:55 | <aho> | one person gets it right, puts it on github |
| 21:55 | <aho> | problem solved |
| 21:55 | <aho> | :> |
| 21:55 | <zewt> | if only things were that easy :) |
| 21:57 | <aho> | tbh, i'd rather use bloody tar files instead of zips |
| 21:57 | <aho> | but that would be super awful, too |
| 21:57 | <zewt> | guh |
| 21:58 | <zewt> | tars are so much more horrible heh |
| 21:58 | <zewt> | trailing index is better than no index :) |
| 22:05 | <aho> | well, that whole thing can be done as "composite format" |
| 22:06 | <zewt> | tars can also only be solid archives |
| 22:06 | <aho> | index = json (can be validated)... and gzipped. each file gzipped. then everything just concatinated |
| 22:06 | <aho> | done :> |
| 22:06 | <aho> | technically not a new format |
| 22:06 | <aho> | :>~ |
| 22:07 | <zewt> | you're stretching "technically" :P |
| 22:07 | <zewt> | don't need to involve tar when doing it that way, though |
| 22:07 | <aho> | would be pretty straighforward though, wouldn't it? |
| 22:08 | <aho> | ye, meant w/o tar |
| 22:08 | <aho> | stuff->gzip->concat |
| 22:09 | <aho> | using json for the index also simplifies things quite a bit |
| 22:10 | <aho> | it's utf-8 and the parser also already exists |
| 22:10 | <zewt> | one nitty thing about gzip is it doesn't include the file size as a header, so if you want to just download the header, you can't tell how much to read in advance ... sort of annoying, i think |
| 22:10 | <aho> | there are also libraries to write it |
| 22:11 | <aho> | mmmh... yea, file length is in the footer :l |
| 22:11 | <zewt> | of course, you could have a tiny initial header (which you'd want anyway, so the file doesn't sniff like a gzip), which includes a magic + the size of the compressed header |
| 22:11 | <aho> | wikipedia mentions optional extra headers... probably hard to create with most default libs |
| 22:11 | <zewt> | i mean with your random idea |
| 22:12 | <aho> | yea |
| 22:12 | <aho> | just looked at gzip's wikipedia entry again for reference |
| 22:12 | <zewt> | couldn't really do it with gzip directly, since you don't want it to have a gzip header at the very beginning |
| 22:13 | <zewt> | or tools wouldn't be able to reliably tell them apart from a plain gzip of json |
| 22:13 | <aho> | true |
| 22:13 | <aho> | also, some UAs do gzip sniffing |
| 22:13 | <aho> | (opera does) |
| 22:14 | <Hixie> | someone asked me for suggestions as to who should review their book on html and web standards, anyone interested? |
| 22:20 | Philip` | notes randomly that Age of Empires 3 (and others in the series) uses zlib-compressed data preceded by the 32-bit filesize preceded by the string "l33t" |
| 22:20 | <aho> | :> |
| 22:21 | <Peter-> | I love that game :) Though not as much as AoE 2 |
| 22:23 | <aho> | zewt, but yea... i think that should work nicely. magic, compressed length of the json thing, json index (gzipped), file1 (gzipped), file2... fileN |
| 22:24 | <aho> | well, maybe 3 byte magic + 1 byte version number :> |
| 22:24 | <zewt> | well, you'd also want a way to have uncompressed data |
| 22:24 | <aho> | gzip can do that |
| 22:25 | <aho> | 18 byte overhead |
| 22:25 | <zewt> | don't know any way to do that with gzip(1) |
| 22:26 | <aho> | gzip 0 = store |
| 22:26 | <zewt> | gzip: invalid option -- '0' |
| 22:26 | <aho> | it automatically switches to store if the compressed thing is bigger than the input |
| 22:27 | <zewt> | need to be able to not attempt to compress at all when you know the file format is already compressed |
| 22:27 | <zewt> | odd that there's no option to do that already though |
| 22:27 | <aho> | http://en.wikipedia.org/wiki/DEFLATE -> Encoding method used for this block type -> 00: a stored/raw/literal section follows, between 0 and 65,535 bytes in length. |
| 22:27 | <zewt> | pretty obvious thing, and any zip tool can do it |
| 22:28 | <zewt> | another thing to think about once you're making a new format: drop crc32, use sha-1, and put the sha-1 in the index, not with each file (as it is with gzip) |
| 22:29 | <aho> | <aho> 18 byte overhead <- +1 byte every 64k ;) |
| 22:29 | <zewt> | benefit: you can tell if your (externally cached) copy of the decompressed data is out of data by just looking at the index |
| 22:29 | <zewt> | which can mean not having to fetch the data at all |
| 22:30 | <aho> | well, you probably want to use this in conjunction with a far future expires header and cache busting |
| 22:30 | <aho> | so, if the RP's content has changed, the path will be different |
| 22:31 | <zewt> | but with a proper hash you can update an archive and clients can (if they're smart enough) only download the changed file |
| 22:31 | <aho> | hum |
| 22:31 | <zewt> | (or files, even quickly using a multi-range Content-Range) |
| 22:31 | <zewt> | request the range for each changed file and get the entire thing streamed with one request |
| 22:32 | <zewt> | (entire thing -> entire set of changed files) |
| 22:32 | <Philip`> | Related to compression: http://virtualdub.org/blog/pivot/entry.php?id=335 looks fun |
| 22:33 | <zewt> | heh my comment at the bottom |
| 22:33 | <zewt> | <- glenn maynard |
| 22:33 | <Philip`> | Seems like you can't always assume tools are competent :-( |
| 22:34 | <aho> | http://www.reddit.com/r/programming/comments/genvz/and_i_thought_my_implementation_of_deflate_was/c1n1tho <- my comment |
| 22:34 | <aho> | reddit is slooooooow :> |
| 22:35 | <aho> | zewt, are there multi-range requests? :o |
| 22:36 | <zewt> | i thought there were, but maybe not (there certainly should have been) |
| 22:39 | <aho> | speaking of which, that diffing stuff they did for google maps is neat |
| 22:39 | <aho> | but to be honest, i still don't really understand how it works :> |
| 22:40 | <aho> | with java/webstart you can also just download a diff of the required jars |
| 22:40 | <aho> | would be cool if there would be something like that out-of-the-box. (no clue how that should look like though) |
| 22:46 | <aho> | ah yea, checksums. with a json index you could use some kind of version string, which could be whatever you want. e.g. a revision number or a checksum (i like md5 -> b64-for-urls -> truncate to 22 chars [last 2 chars are always '==']) |
| 22:47 | <zewt> | ew |
| 22:48 | <aho> | works great for cache busting ;) |
| 22:48 | <zewt> | hex encoding for hashes is pretty standardized |
| 22:48 | <aho> | hex is bigger |
| 22:48 | <zewt> | really not something worth breaking from the crowd about :) |
| 22:48 | <aho> | well, if it's a string you can use whatever you want |
| 22:49 | <zewt> | better off using the same thing everyone else in the universe uses whenever possible |
| 22:49 | <zewt> | i wonder how much deflate compresses lots of hex strings |
| 22:50 | <aho> | well, 32 chars vs 22 chars |
| 22:50 | <aho> | totally worth it! ;D |
| 22:51 | <zewt> | gzip compresses a 2048-byte block of random hex to 1174--that's really good, actually (with 1024 being optimal, ignoring headers) |
| 22:55 | <aho> | b64 is about the same |
| 22:55 | <zewt> | gzipped base64, 1086 bytes ... very close |
| 22:55 | <aho> | b64=33% bloat, gzip gets rid of that again :> |
| 22:55 | <zewt> | (well--less close if it's a lot of data, but for a file index it's close enough) |
| 22:56 | <zewt> | and being able to look at the index (with your eyes and not special tools), pull out an sha-1, run sha1sum on a file and compare them (again with no special tools)--that's a general real-world win |
| 22:57 | <zewt> | can't do that if your hashes are encoded in an unusual way |
| 22:58 | <aho> | i do know one other person who does it the same way and who came up with it independently :> |
| 22:58 | <zewt> | also stop with the md5 already it's 2011 :P |
| 22:59 | <aho> | if you're only interested in detecting changes, md5 works fine |
| 23:00 | <zewt> | no reason to use md5 in anything new--default to sha-1 |
| 23:00 | <zewt> | even if there's no particular reason to for an application, it helps to get out of the habit :P |
| 23:01 | <aho> | why not skein then? :> |
| 23:02 | <aho> | or sha-2 for that matter |
| 23:05 | <zewt> | well, sha-1 isn't considered obsolete today; md5 is |
| 23:08 | <aho> | sha-1 outputs 20 bytes instead of 16... meh :I |
| 23:08 | <aho> | http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms |
| 23:09 | <aho> | mhmh... ripemd-128 :> |
| 23:09 | <aho> | never heard of that one |