| 00:47 | <Hixie> | ok i made some pretty risky changes, please let me know if anything broke with the spec |
| 00:56 | <tantek> | heh |
| 00:57 | <Domenic> | Hixie: browsing the diff, seems like the web dev edition might be broken by removal of some of the <!-- -->s? |
| 01:02 | <caitp> | http://jsfiddle.net/8cQGe/ reproduction is a bit clearer in this case if anyone wants to clarify that |
| 01:20 | <Hixie> | Domenic: yeah, i mailed ben about it. i need to figure out what he needs. |
| 04:05 | <MikeSmith> | Hixie: I guess https://code.google.com/p/chromium/issues/detail?id=377581 is the fix for the 408s problem in Chrome |
| 04:06 | <MikeSmith> | Hixie: and I think the w3c systems team is also looking at making a HAProxy to deal with it http://blog.haproxy.com/2014/05/26/haproxy-and-http-errors-408-in-chrome/ |
| 04:11 | <MikeSmith> | *HAProxy change |
| 04:51 | <montecfel> | Can somebody tell me if it's yet possible to change the colors around of a canvas? That is, fast. Not loading all the pixel data in an array, looping through it all and changing the values, but actual fast manipulation of the existing pixels on a canvas? |
| 04:52 | <montecfel> | Also, I do not mean putting a rectangle on top of the image that is transparent. That doesn't change the color in the manner I wish. |
| 04:52 | <SamB> | montecfel: what, you want pallette cycling??? |
| 04:52 | <montecfel> | SamB: Not really that. |
| 04:52 | <montecfel> | This would not be limited to the 256 color palette of olden times. |
| 04:52 | <montecfel> | Which was damn annoying trying to squeeze in all necessary shades. |
| 04:53 | <montecfel> | I need to gradually make it more nightely in my tile-based game. |
| 04:53 | <montecfel> | Without drawing 100 copies of each sprite with slightly different colors on it. |
| 04:53 | <montecfel> | Or pre-calculating this at the start of the game. |
| 04:53 | <montecfel> | Which would take up insane amounts of RAM and CPU. |
| 04:55 | <montecfel> | You catch my drift? |
| 05:10 | <roc> | WebGL |
| 05:11 | <SamB> | yeah, WebGL shaders would presumably work |
| 05:11 | <SamB> | never run on this system though |
| 05:59 | <montecfel> | SamB: Huh? |
| 05:59 | <montecfel> | roc and SamB: Well, I use Canvas 2D. |
| 05:59 | <montecfel> | Not Canvas WebGL. |
| 05:59 | <montecfel> | Because it's 2D graphics. |
| 05:59 | <SamB> | my system doesn't appear to support WebGL |
| 06:00 | <roc> | WebGL is the best way to do fast 2D graphics too. |
| 06:00 | <montecfel> | Many systems don't. |
| 06:00 | <SamB> | and OpenGL has been put to quite good use for 2D graphics for quite some time |
| 06:00 | <montecfel> | Why on Earth would they have completely separate APIs where one isn't accelerated? |
| 06:00 | <montecfel> | Doesn't add up. |
| 06:00 | <roc> | 2D is hard to accelerate |
| 06:00 | <roc> | WebGL gives you much more direct access to the GPU. |
| 06:00 | <montecfel> | That doesn't really answer my question, though. |
| 06:01 | <montecfel> | Why not do acceleration under the hood? |
| 06:01 | <montecfel> | In fact, I thought they were accelrated. |
| 06:01 | <montecfel> | MS IE 9+ sure as hell are. |
| 06:01 | <SamB> | at least, nobody has bothered to do 2D-specific hardware acceleration for a LOOONG TIME |
| 06:01 | <roc> | yeah |
| 06:01 | <roc> | everybody does |
| 06:01 | <montecfel> | Ultra-fast 2D drawing. |
| 06:01 | <roc> | but it's still not as good |
| 06:01 | <SamB> | not saying canvas doesn't use accelaration, mind |
| 06:01 | <montecfel> | Well, it's slow like a freaking heck to read and change pixels. |
| 06:02 | <montecfel> | I bet there is some well-hidden way to do exactly what I want, in a super nice and fast way. |
| 06:02 | <roc> | ironically that's actually slower with GPU-accelerated canvas, because you have to get the pixels back from VRAM |
| 06:02 | <montecfel> | Which doesn't involve reading in the pixel data and awkwardly looping through it and whatnot. |
| 06:02 | <SamB> | montecfel: shaders are basically the way to do it |
| 06:02 | <roc> | montecfel: depending on your effect, you may be able to do what you want with fancy operators |
| 06:02 | <SamB> | roc: don't suppose there's a way to ask for a not-accelerated canvas? |
| 06:02 | <montecfel> | But I have zero experience in WebGL, and it's different from Canvas 2D, and it's poorly supported? |
| 06:03 | <montecfel> | Possibly with typed arrays, but they don't seem much faster than general JS arrays. |
| 06:03 | <montecfel> | It feels criminal to, upon load, make 100 copies of each sprite/tile in my game, and keep them all in RAM, just to be able to shade in/out from night and day. |
| 06:04 | <montecfel> | What does WebGL code even look like for 2D stuff? |
| 06:04 | <montecfel> | And shaders... ugh... |
| 06:05 | montecfel | does not like the idea of diving into that. |
| 06:06 | <roc> | montecfel: maybe you can use the "lighten" or "darken" operators |
| 06:06 | <roc> | with globalCompositeOperation |
| 06:07 | <montecfel> | Hmm... |
| 06:07 | <montecfel> | Well, I need to set the R, G and B separately. |
| 06:21 | <Domenic> | +1 webgl shaders |
| 06:21 | <Domenic> | used them to great affect in a hackathon to make a nightvision filter |
| 06:27 | <Domenic> | Does anything specify javascript: URLs? cf. https://github.com/tmpvar/jsdom/issues/823. annevk? |
| 06:29 | <montecfel> | I don't understand how to use WebGL. |
| 06:31 | <montecfel> | ImageData.data |
| 06:31 | <montecfel> | Is a Uint8ClampedArray representing a one-dimensional array containing the data in the RGBA order, with integer values between 0 and 255 (included). |
| 06:31 | <montecfel> | Oh. It's a typed array. |
| 06:31 | <montecfel> | And still so damn slow. |
| 06:31 | <Hixie> | MikeSmith: wow, that's a dumb protocol design. totally racy. |
| 06:31 | <montecfel> | "Clamped" is a weird term. |
| 09:47 | <MikeSmith> | anybody know if there are people from Nashorn on TC39 |
| 09:49 | <MikeSmith> | Jim Laskey? |
| 16:27 | <hsivonen> | MikeSmith: I located the build.py bug that prevented me from launching re-deploying validator.nu the other day |
| 16:28 | <MikeSmith> | hsivonen: glad for that |
| 16:28 | <hsivonen> | there's now a command line parameter with a space in it and the shell script generation option doesn't deal |
| 16:28 | <MikeSmith> | oh.. |
| 16:28 | <MikeSmith> | sorry about that |
| 16:28 | <MikeSmith> | did I add that param? |
| 16:28 | <MikeSmith> | I must have |
| 16:28 | <hsivonen> | what's the pythonic way to say "take this array of strings and give me an array where each item has been surrounded by single quotes"? |
| 16:28 | <hsivonen> | I'm pretty sure I didn't :-) |
| 16:29 | <MikeSmith> | as far as your question, I'm not an idiomatic pyton coder |
| 16:30 | <MikeSmith> | but we could change that param to have an equals sign between the name of the switch and the value |
| 16:30 | MikeSmith | looks back to see what switches he added |
| 16:32 | <gsnedders> | hsivonen: ["'%s' % x for x in foo] is what I'd claim is Pythonic |
| 16:34 | <jgraham> | gsnedders: I'd claim that's a SyntaxError :p |
| 16:35 | <MikeSmith> | hsivonen: the value for the "--user-agent" switch I guess. So ignore what I said before about the equals-sign thing. That won't make any difference of course |
| 16:36 | <gsnedders> | jgraham: shut up you |
| 16:45 | <Hixie> | wtf is http://blog.udn.com/bbuqt56/13228080 and why is it linking to my blog |
| 16:47 | <tantek> | linkback spam? |
| 16:47 | <tantek> | (which now made it into archives ;) ) |
| 16:49 | <Hixie> | why would someone link-back spam to a random page on my blog with bogus arguments? |
| 16:51 | <TabAtkins> | hsivonen: Alternately, map("'{0}'".format, arr) |
| 16:51 | TabAtkins | has used that before. |
| 16:51 | <TabAtkins> | But the list comprehension works just as well. |
| 16:54 | gsnedders | would claim that's less idiomatic |
| 16:56 | <tantek> | Hixie, on the web, spam is the simplest (Occam's razor) explanation for many behaviors. |
| 16:57 | <Hixie> | granted |
| 16:57 | <Hixie> | but i don't understand what they hoped to achieve here |
| 16:57 | <tantek> | get you to post a link in the channel? |
| 16:57 | <MikeSmith> | tantek: I thought broken code was the simplest explanation |
| 16:58 | <tantek> | MikeSmith - true - and of that, databases are the biggest subset. spam is second to broken code. |
| 17:02 | <Hixie> | tantek: that's some convoluted spam operation |
| 17:02 | <Hixie> | tantek: also, i'm probably a poor target, given that i work at google, in the knowledge department... |
| 17:03 | <tantek> | and for that we can go with MikeSmith's explanation - broken code - why your link was picked - no idea |
| 17:03 | <tantek> | or lazy code |
| 17:03 | <MikeSmith> | yeah that too |
| 17:05 | <Hixie> | in other news, it's absurd how many RSS readers are still crawling my RSS feed |
| 17:06 | <Hixie> | it hasn't changed since 2011 |
| 17:06 | <Hixie> | time to 410 it, i guess |
| 17:06 | <tantek> | maybe they're optimists |
| 17:06 | <tantek> | Hixie - do it - then we can point out that you're killing RSS! |
| 17:07 | <Hixie> | rss is dumb and should have died long ago :-P |
| 17:07 | <tantek> | it is dying, slowly: http://indiewebcamp.com/feed#Shutdowns |
| 17:08 | <Hixie> | also i love the crawlers that clearly lie in their referrer field |
| 17:09 | <tantek> | Hixie, I for one see most of my bandwidth go to bots lying that they're IE5.5 |
| 17:09 | <Hixie> | i just had one claiming to be firefox on windows 3.1. |
| 17:10 | <tantek> | nice |
| 17:17 | <zewt_> | some non-browser but non-bot stuff make up referer, I think lftp puts the url itself in |
| 17:17 | <zewt_> | useful when pasting in a file url to download since it convinces a lot of dumb sites to work |
| 17:31 | <Domenic> | I still <3 RSS... not as a format, but as a user experience. |
| 18:27 | <TallTed> | RSS (and Atom) is just a poor but sometimes pretty reinvention of NNTP. Fixing/evolving NNTP would be so much better. |
| 18:28 | <Domenic> | Why? What practical benefits would that give over RSS? |
| 18:37 | <Hixie> | TallTed: NNTP is rather different imho |
| 18:37 | <Hixie> | fundamentally the problem with RSS or Atom is that they're poll-based |
| 18:37 | <Hixie> | which is just a broken model |
| 18:37 | <tantek> | Hixie, what do you think of Atom via PuSH? |
| 18:38 | <kmc> | can scripts change a Document's quirks mode? can the quirks mode change during parsing other than by action of the parser? |
| 18:38 | <Hixie> | well atom's pretty horrible in and of itself, as a separate issue |
| 18:38 | <SamB> | Hixie: NNTP is poll-based too, no? |
| 18:38 | <Hixie> | i'm not advocating nntp either |
| 18:38 | <SamB> | though at least you poll, like, two servers instead of zillions |
| 18:40 | <Hixie> | tantek: i think PuSH is definitely the better model |
| 18:40 | <Hixie> | tantek: though i can't help but wonder why it seems that for most purposes, there just isn't that much demand for this kind of thing. |
| 18:41 | <Hixie> | at the client end, i mean |
| 18:41 | <SamB> | Hixie: Well, you're already familiar with one push-based protocol in common use, yes? Oh, but not usually on the client end ... |
| 18:41 | <Hixie> | podcast readers and feed readers are the only real end-user usage of RSS/Atom, and they're pretty low in usage |
| 18:41 | <tantek> | Hixie, ironically, there is from a user level AKA "push notifications" but that has yet to translate into decent simple reliable protocols for that at the server level. PuSH is a step but by no means a very good answer. |
| 18:41 | <SamB> | are there any good feed readers now? |
| 18:42 | <SamB> | um, hey, what's the lowercase u |
| 18:42 | <tantek> | SamB: http://indiewebcamp.com/PuSH |
| 18:43 | <Hixie> | i would have linked to https://code.google.com/p/pubsubhubbub/ :-) |
| 18:43 | <Hixie> | tantek: the push notifications that users seem to want are things like instant messaging and calendar appointments and incoming phone calls and the like |
| 18:43 | <Hixie> | tantek: all of which have their own proprietary or dedicated protocols |
| 18:43 | <tantek> | Hixie - that page is less up to date unfortunately - as a nearly all such project/corporate pages that don't have some wiki-ness to them. |
| 18:43 | <tantek> | It's like the TR problem |
| 18:44 | <Hixie> | code.google.com has wikiness |
| 18:44 | <Hixie> | but sure |
| 18:44 | <tantek> | Hixie - right " have their own proprietary or dedicated protocols" - we're still at that phase in the technology curve for user/web scale notifications |
| 18:44 | <SamB> | code.google.com often has incomplete wikiness |
| 18:45 | <SamB> | "web scale" is a buzzword, you know that right? |
| 18:45 | <tantek> | SamB - I kind of assume all projects there are dead now, either abandoned or moved to github |
| 18:45 | <Hixie> | tantek: well it's not clear to me what the user desire is at the end of the day |
| 18:45 | <Hixie> | tantek: most people don't seem to care for web sites to push them notifications of new content. |
| 18:45 | <tantek> | Hixie, sure, there are probably several different use-cases to unpack |
| 18:45 | <SamB> | tantek: I think I've seen one project that was for some reason using google code for issues but github for pull requests |
| 18:46 | <SamB> | libarchive, iirc |
| 18:46 | <Hixie> | tantek: at least, not in the indiscriminate ways that RSS/Atom/PuSH do |
| 18:46 | <tantek> | Hixie "web sites" can be calendar, or even IM/IRC, and with WebRTC, phone calls too |
| 18:46 | <Hixie> | SamB: "web scale" is actually a pretty important concept that a lot of people don't get |
| 18:46 | <SamB> | Hixie: that's almost the same as a buzzword |
| 18:46 | <tantek> | it's jargon, not the same as a buzzword |
| 18:46 | <Hixie> | tantek: right |
| 18:47 | <SamB> | I mean, um, people seem to use it without actually meaning anything in particular a lot of the time |
| 18:47 | <tantek> | SamB, your skepticism is reasonable. |
| 18:47 | <Hixie> | tantek: it's messages about application state, not messages about all new site content, though. |
| 18:47 | <Hixie> | SamB: a lot of jargon is used by many people as if it was a buzzword |
| 18:47 | <SamB> | if a what was jargon gets too much buzz, it can lose value as jargon |
| 18:48 | <Hixie> | SamB: but when tantek (or I, or most people in #whatwg) say "web scale", it isn't empty of meaning |
| 18:48 | <SamB> | or, maybe, it's just that I personally am confused by the buzz |
| 18:48 | <tantek> | Hixie - simple example: txt messages - they're all new (site) content |
| 18:48 | <SamB> | dunno ;-) |
| 18:48 | <Hixie> | tantek: i guess the distinction i'm making is between user-specific content and public content |
| 18:48 | <tantek> | so like Amber Alert txt messages then? |
| 18:49 | <Hixie> | tantek: those are an interesting case |
| 18:49 | <Hixie> | tantek: not sure they generalise, though |
| 18:49 | <tantek> | Hixie - another: weather alerts: http://www.nws.noaa.gov/com/weatherreadynation/wea.html |
| 18:49 | <tantek> | for cities, transit system alerts |
| 18:50 | <Hixie> | all of these are somewhat user-specific, in that they're geographically scoped |
| 18:50 | <Hixie> | but yeah |
| 18:50 | <tantek> | they're public-ish |
| 18:50 | <Hixie> | sure |
| 18:50 | <SamB> | oh yeah, it'd certainly be handy to know about impending weather or SEPTA service interruptions ;-) |
| 18:51 | <Hixie> | but you'd want your system to automatically provide you with alerts about the transit problems near you, you wouldn't want to subscribe to them manually |
| 18:51 | <tantek> | Hixie, another more recent *global* example: World Cup scores |
| 18:51 | <tantek> | (as they happen - as in individual goals) |
| 18:51 | <SamB> | why do I keep thinking of twitter |
| 18:51 | <Hixie> | yeah, but how many users would want to manually subscribe to those? as opposed to just being told them if they've shown interest? |
| 18:52 | <tantek> | Hixie - yes, many "subscriptions" you'd want to be automatic on/off rather than manually curating - we've come to that conclusion in the #indiewebcamp community as well. |
| 18:52 | <Hixie> | i mean, people aren't subscribing to Atom feeds for goals en-masse |
| 18:52 | <SamB> | Hixie: the latter sounds kind of creepy |
| 18:52 | <Hixie> | creepy how? |
| 18:52 | <tantek> | It's one of the reasons feed readers died |
| 18:52 | <tantek> | too much curating |
| 18:52 | <Hixie> | tantek: right |
| 18:52 | <Hixie> | tantek: that's kind of my point |
| 18:52 | <tantek> | it's also going to doom the silos, Twitter, FB, G+ etc. because you need to do too much curating of who/what you follow |
| 18:53 | <SamB> | creepy like Facebook crossed with Amazon? |
| 18:53 | <tantek> | Facezon! |
| 18:53 | <Hixie> | tantek: i assume that's why G+ and FB are working so hard on automatic curation |
| 18:53 | <Hixie> | SamB: i don't understand what you mean by "creepy" here |
| 18:53 | <tantek> | Hixie - in FB's case, they're also doing it for academic studies of emotional manipulation / propation. |
| 18:54 | <Hixie> | yeah, that was a fascinating study |
| 18:54 | <SamB> | some of us like to pretend we've got something resembling privacy |
| 18:54 | <Hixie> | SamB: ? |
| 18:54 | <Hixie> | SamB: what's privacy got to do with this |
| 18:54 | <SamB> | is the automation meant to be client-side? |
| 18:54 | <SamB> | in terms of figuring out what feeds to follow? |
| 18:54 | <Hixie> | SamB: what do you mean by "client-side"? |
| 18:54 | <tantek> | Hixie - agreed, automatic curation is a very hard problem |
| 18:54 | <Hixie> | SamB: i don't understand what you mean by "privacy" in this context |
| 18:55 | <Hixie> | i don't see anything in what we've discussed that would imply anyone else being able to see anything about you |
| 18:56 | <Hixie> | tantek: as you say, though, it's pretty much going to be a requirement. |
| 18:56 | <Hixie> | tantek: cos people hate to do manual curation. |
| 18:56 | <SamB> | Hixie: who is meant to do the automatic curation? |
| 18:56 | <SamB> | or rather, what? |
| 18:56 | <Hixie> | SamB: some software somewhere. |
| 18:57 | <SamB> | and what is the nature of the information on which it will base its choices? |
| 18:58 | <Hixie> | whatever you've provided the software, e.g. if it's twitter, who you follow, what you've tweeted, etc |
| 18:59 | <Hixie> | ideally, every action you've ever taken and every thought you've ever had |
| 18:59 | <Hixie> | though i doubt we'll get there any time soon, the tech isn't there yet :-) |
| 19:00 | <SamB> | Hixie: and you're confused about why I'm bringing up privacy *why*? |
| 19:00 | <tantek> | HIxie, I don't think you're helping with not creeping out SamB ;) |
| 19:00 | <Hixie> | SamB: privacy is about what other people see. there's no other people in this discussion. |
| 19:01 | <SamB> | well, I guess my concern is basically with how vague "somewhere" is |
| 19:01 | <Hixie> | well given the volume of data and the processing requirements to handle it, probably some datacenter. |
| 19:02 | <tantek> | Hixie, put another way, manual curation doesn't scale, not even to "average" friend group sizes these days |
| 19:02 | <tantek> | nevermind all the more public-ish things you want to be notified about |
| 19:02 | <SamB> | so will this data center be run by the NSA directly, or ... |
| 19:03 | <tantek> | SamB - no they just get their copy as usual |
| 19:03 | <SamB> | so it gets used for advertising purposes *and* policing then? |
| 19:04 | <Hixie> | SamB: let me assure you than the NSA can far more easily slurp data off your personal hardware than it can out of the datacenter of a company which pays teams of the world's security experts to specifically secure the data against agencies like the NSA |
| 19:04 | <Hixie> | _faaaar_ more easily |
| 19:04 | <SamB> | Hixie: I believe it |
| 19:04 | <Hixie> | so you brought up the NSA because...? |
| 19:06 | <SamB> | well, what company did you have in mind exactly? |
| 19:07 | <Hixie> | it doesn't really matter, since the NSA can get to your hardware as easily or more easily than any company's. |
| 19:07 | <SamB> | yes but I think someone would notice if they actually got to my hardware |
| 19:08 | <Hixie> | even if you used the NSA itself as your curation provider, your data would still be no less secure than if you used your own hardware. |
| 19:08 | <Hixie> | lol no |
| 19:08 | <Hixie> | see the stuff snowden leaked. |
| 19:08 | <gsnedders> | Hell, I'd be kinda worried just going over any border crossing |
| 19:09 | SamB | imagines trying to carry a desktop across a border ... |
| 19:09 | <Hixie> | they intercept hardware delivers and replace the hardware with identical-looking hardware with built-in wifi hotspots that they can connect to. |
| 19:09 | <Hixie> | deliveries. |
| 19:09 | <Hixie> | including, e.g. USB cables |
| 19:09 | <Hixie> | if your threat model includes the NSA, then the only way you're going to be able to come close to thinking you're secure is if you have the resources of a small nation state. |
| 19:09 | <Hixie> | (like, for example, some large companies do) |
| 19:10 | <gsnedders> | but do you trust the SoC? |
| 19:10 | <Hixie> | which SoC? |
| 19:11 | <gsnedders> | any |
| 19:11 | <Hixie> | i don't understand your question |
| 19:11 | <Hixie> | if you designed and built it, then sure |
| 19:11 | <gsnedders> | are you sure the built product is what you designed? |
| 19:11 | <SamB> | you think they can squeeze a wifi hotspot into an SoC? |
| 19:12 | <Hixie> | SamB: um, every phone has a wifi hotspot on an SoC |
| 19:12 | <gsnedders> | the antenna are a fair bit larger, but I'm sure you can work around that somehow |
| 19:12 | <Hixie> | gsnedders: if you took the data from your design to fab and so forth, sure |
| 19:12 | <SamB> | technically not just the SoC, but I see your point |
| 19:12 | <Hixie> | if the hardware the wifi hotspot is being put into is a USB cable, you have a gigantic antenna to work with. |
| 19:13 | <SamB> | no need to add much if the hardware was already going to be provided anyway |
| 19:13 | <Hixie> | i mean, the victim in the scenario here literally provides the antenna _as the product they're trying to get_ |
| 19:13 | <Hixie> | anyway |
| 19:14 | <Hixie> | as i said |
| 19:14 | <Hixie> | if the NSA is in your threat model, then your only real choices are: 1. no computer data at all, 2. be a nation state or large company, 3. employ the services of a nation state or large company. |
| 19:14 | <SamB> | so do they really do this to the general public? |
| 19:14 | <SamB> | I mean, as a whole? |
| 19:15 | <Hixie> | no, of course not. not in any way that matters to you. |
| 19:15 | <Hixie> | unless you're the girlfriend of an NSA agent, or are two or three steps removed from a terrorist suspect |
| 19:15 | <Hixie> | or make phone calls |
| 19:15 | <Hixie> | or send texts |
| 19:16 | <Hixie> | btw, if you're worried about the NSA seeing your automatically curated feeds, it's going to blow your mind when you realise that your credit card company sees everything you buy and your ISP sees everything you do online, and both of those are probably sharing that data with the NSA too |
| 19:16 | <SamB> | well, I can be fairly certain they aren't responsible for the *design* of my phone; if they were, surely the piece of junk they call a "browser" would actually function, no? |
| 19:18 | <SamB> | Hixie: well, somehow having all that preferences information already distilled just makes it worse ... |
| 19:19 | <SamB> | I mean, in my mind, not in reality |
| 19:19 | <SamB> | anyway I should probably go do something useful rather than worrying about the fiction of privacy ... |
| 19:19 | <Hixie> | yeah, god forbid the NSA know what football team you're rooting for |
| 19:19 | <Hixie> | your privacy is unaffected by what we're talking about |
| 19:19 | <Hixie> | (unless you care about the NSA) |
| 19:20 | <Hixie> | (but even then, your privacy isn't any _more_ affected by what we're talking about than it already is.) |
| 19:21 | SamB | is beginning to feel like the NSA could have intentionally not reported heartbleed so that it could later serve as a convenient distraction from their ACTUAL methods of attack ... |
| 19:22 | <caitp> | maybe they did intentionally not report heartbleed |
| 19:22 | <caitp> | maybe martians have landed in DC |
| 19:23 | <Hixie> | the NSA claim that they didn't know about that OpenSSL bug, and people who claim to have looked through logs claim to not have seen any evidence that anyone was exploiting that bug early |
| 19:24 | <SamB> | I mean, maybe that's the kind of thing it would have made sense for them to do, given knowledge of the existance of heartbleed. Not to say that I believe that they knew about it. |
| 19:24 | <Hixie> | but that bug's an interesting example of precisely what i meant by large companies having large security teams whose job it is to secure their users' data from the NSA |
| 19:24 | <gsnedders> | on the other hand, the large companies are probably larger targets |
| 19:24 | <SamB> | The idea being that they actually would do nothing with it, saving it for later when it would cause a huge stir |
| 19:25 | <SamB> | (but don't ask me how they would arrange for it to be discovered) |
| 19:27 | <caitp> | they have a specific word for revealing security vulnerabilities in the least helpful and most harmful way possible |
| 19:27 | <Hixie> | SamB: given how much of the US gov't depends on OpenSSL, I _highly_ doubt that they would be that reckless |
| 19:27 | <SamB> | Hixie: point |
| 19:27 | <SamB> | maybe a bug that was less bad, but not clearly so, would work better for such a purpose |
| 19:28 | <caitp> | > implying agencies of government necessarily care if they step on another agencies toes |
| 19:28 | <gsnedders> | the NSA's mission includes defence against sigint |
| 19:29 | <SamB> | well, most of my programs will exit upon recieving sigint, so I think they've failed miserably |
| 19:30 | <caitp> | heh |
| 19:30 | <tantek> | is there a variant of Godwin's law like Snowden's law that says that every conversation online ends up being about the NSA? E.g. scrollback and see how fast we got from RSS to NSA. |
| 19:30 | <caitp> | high quality puns |
| 19:31 | <SamB> | I mean, I guess it's silly for me to worry so much more when you talk about actually *using* information that I've not hesitated to let e.g. google have in the past to actually make the product work better |
| 19:31 | <SamB> | I mean I used reader for a while, was rather sad to see it go ... |
| 19:32 | <SamB> | (especially since most sites have terrrible, uh, "retention" on their feeds) |
| 19:33 | <tantek> | SamB - another reason why separate feed files were a bad idea |
| 19:33 | <tantek> | modern approaches now just markup the visible content in the HTML |
| 19:33 | <SamB> | hmm |
| 19:34 | <SamB> | I think what was happening was they didn't want stupid clients to download the entire history of the world at every poll |
| 19:34 | <tantek> | more on feed files (problems, superseded by) http://indiewebcamp.com/feed_file |
| 19:35 | <SamB> | how would you pull in the entire history of everything using these modern approaches? |
| 19:35 | <tantek> | SamB - is that a use case for anyone other than a search engine like google? |
| 19:35 | <SamB> | and why am I suddenly wishing for a <body> tag to put inside <article> ;-P |
| 19:36 | <tantek> | thus: web spider |
| 19:36 | <tantek> | SamB - see previous debate about a <content> tag - pretty sure that's in an FAQ somewhere (why we don't need one) |
| 19:36 | <SamB> | tantek: well, it used to be nice and convenient to read all of that stuff in reader, especially before it started auto-marking everything as read before a certain date ... |
| 19:37 | <caitp> | content doesn't really have much of a semantic meaning does it |
| 19:37 | <SamB> | tantek: but ... comments ... aren't ... content ... of the ... article! |
| 19:37 | <caitp> | "there is stuff here" |
| 19:37 | <caitp> | section[for=comments] ? |
| 19:37 | <tantek> | SamB - sure. are you publishing or parsing? |
| 19:39 | <SamB> | well, it sounds like these "modern approaches" involve scraping the site, but you might want to see just the main content without all the trappings/comments ... |
| 19:39 | <tantek> | no scraping - all parsing |
| 19:40 | <SamB> | I'm not sure I follow the distinction ;-) |
| 19:40 | <tantek> | yup - content of a post (vs. comments, faves, reposts, reply-context etc.) has been solved |
| 19:40 | <tantek> | parsing has a spec that publishers conform to, scraping is one-off per site. not unlike site-specific APIs. which break when sites change. |
| 19:40 | <tantek> | big difference |
| 19:40 | <SamB> | tantek: okay, fine, I meant "parsing" |
| 19:41 | <tantek> | cool - yeah if you want to chat modern approaches for distinguishing post content vs. comments, faves, reposts, reply-context etc. come on by #indiewebcamp |
| 19:41 | <SamB> | tantek: got a blog that implements it? |
| 19:42 | <tantek> | SamB - several! depends on what you're looking for |
| 19:43 | <caitp> | i don't know why I ever bother with debug builds when a release clobber build just sails through so much faster |
| 19:44 | <SamB> | caitp: a what now? |
| 19:45 | <caitp> | don't mind me I'm yappin |
| 19:45 | <SamB> | I hope you always build with -g |
| 19:46 | <caitp> | have you ever seen a lithium ion battery explode? |
| 19:47 | <caitp> | that's the main reason not to compile/link with symbols and debug info, that's frankly terrifying |
| 20:50 | <wanderview_> | this is probably a question for annevk, but does anyone remember why fetch Headers require maintaining ordering? what use case requires controlling the ordering of headers? |
| 21:49 | <GPH-Hickory> | wanderview_: Perhaps for when duplicate headers overwrite each other? (Just guessing.) |
| 21:52 | <Hixie> | oops |
| 21:52 | Hixie | accidentally clobbers the spec |
| 21:53 | <caitp> | does that mean we can rewrite HTML from the beginning? horray! |
| 21:54 | <gsnedders> | Unfortunately it's only the spec, not all the legacy :( |
| 21:54 | <caitp> | :'( |
| 22:03 | <cabanier> | Domenic: ping |
| 22:03 | <Domenic> | cabanier: pong |
| 22:03 | <cabanier> | Domenic: about the DOMRectReadonly object, why can't we treat it as just an interface? |
| 22:04 | <Domenic> | cabanier: what is an interface? WebIDL interface === JavaScript class |
| 22:04 | <cabanier> | Domenic: it seems you're going out of your way to make it the same object. |
| 22:04 | <Domenic> | cabanier: I agree, but that is roc's requirement, so that you can monkeypatch a common prototype class. My suggestion was just to have a DOMRectUtils mixin. |
| 22:04 | <cabanier> | Domenic: even if it has no constructor? |
| 22:05 | <Domenic> | cabanier: yes; remember there is no such thing as "no constructor" in JS, just "constructor which throws unless you pass it a secret" |
| 22:05 | <cabanier> | Domenic: but there are a lot of objects like that in the web platform. You can't new a canvas element for instance |
| 22:06 | <Domenic> | cabanier: EXCEPT that WebIDL has a special exception for interfaces that are [NoInterfaceObject] and only ever used with `inherits` instead of `:`; those are called "supplemental interfaces" |
| 22:06 | <cabanier> | Domenic: maybe domrectreadonly should be a dictionary |
| 22:06 | <Domenic> | cabanier: yes, and we are trying to fix those |
| 22:06 | <Domenic> | cabanier: well, that might be OK, but what about the left/right/top/bottom :-/ |
| 22:06 | <cabanier> | Domenic: var c = new HTMLCanvasElement(); ? |
| 22:07 | <cabanier> | Domenic: too bad that those attributes already shipped.... |
| 22:08 | <cabanier> | Domenic: can't they be implemented with JS? I agree it's failry magical |
| 22:08 | <Domenic> | cabanier: I think they are useful... either separate DOMQuadBounds and DOMRect classes, or DOMRectReadOnly and DOMRect classes, seem OK. |
| 22:08 | <cabanier> | s/failry/fairly |
| 22:08 | <Domenic> | cabanier: sorry, can't what be implemented with JS? |
| 22:09 | <cabanier> | left/right/top/bottom as attribute getter functions that do the calculation |
| 22:09 | <gsnedders> | why not? |
| 22:10 | <Domenic> | they could be, but then there would be separate getters for every instance... classes are nice since they let you reuse getters (or methods) across multiple instances |
| 22:10 | <cabanier> | Domenic: but a dictionary defines everything new every time so that would be consistent |
| 22:11 | <Domenic> | cabanier: yeah, it'd be consistent, agreed. A little wasteful I guess, but not horrible. |
| 22:17 | <cabanier> | Domenic: then DOMRectReadOnly would just be an Object and DOMQuad would keep a reference to that object |
| 22:34 | <Domenic> | cabanier: that seems to kind of contradict the stated design goals, e.g. then people can modify quad.bounds.x and it'll be inconsistent with the quad itself. But I know a lot of people would argue that's more JavaScriptey anyway---the reflection of the object in the API can be messed with, even if the quad itself is not impacted. |
| 22:35 | <cabanier> | Domenic: can 'x' not be readonly in the dictionary? |
| 22:36 | <Domenic> | cabanier: well, I guess it could be a "dictionary" full of getters? E.g. `{ get x() { return 5; }, get y() { return 10; } }` |
| 22:37 | <cabanier> | Domenic: yes, for a quad they would pull it out of the quad. |
| 22:42 | <Domenic> | cabanier: I guess I don't see the advantage over a DOMQuadBounds class? |
| 22:43 | <Domenic> | cabanier: you end up writing a (browser-internal) factory function that is e.g. createRectDictionaryFromDomQuad(quad) { return { get x() { ... }, ... } } |
| 22:44 | <Domenic> | cabanier: which doesn't seem any better than creating a (user-exposed) constructor function DOMQuadBounds(quad) { ... } |
| 22:44 | <Domenic> | both are better than a throw-without-secret constructor, definitely |
| 22:45 | <Domenic> | (note that you can't hide constructors in JS, since they are always accessible via the .constructor property on instances. Whereas factory functions that return simple objects can be hidden.) |
| 22:46 | <cabanier> | Domenic: you avoid exposing another object to the global namespace |
| 22:46 | <cabanier> | Domenic: and avoid type checking when you pass in a DOMRectReadOnly |
| 22:47 | <Domenic> | cabanier: I think you can accomplish both of those though. The type checking definitely; input should never be a DOMRectReadOnly, just a DOMRectInit or something |
| 22:48 | <cabanier> | Domenic: yes. |
| 22:48 | <Domenic> | cabanier: the avoiding-exposing-an-object thing is a bit trickier since we'd need to fix WebIDL. But there is no reason in JS you cannot both (a) have a constructor; (b) decide not to make a global variable pointing to that constructor. |
| 22:48 | <Domenic> | The fact that having a constructor means it must be on the global in WebIDL is just a bug in WebIDL. |
| 22:48 | <Domenic> | it'll be a very bad bug once browsers start shipping modules :P |
| 22:49 | <cabanier> | Domenic: it might be a fundamental browser feature |
| 22:49 | <cabanier> | Domenic: so fixing it might take a while, if you can even convince them to do so |
| 22:49 | <cabanier> | s/feature/design flaw/ |
| 22:50 | <Domenic> | cabanier: that's fair. But we could have a spec that's slightly ahead of the browsers here. And browsers could either expose an extra global (risky), or have a throwing constructor. But as long as the throwing constructor is spec-uncompliant, I am happy. |
| 22:53 | <cabanier> | Domenic: thanks! I'm going to ponder this a bit (it's time to go to sleep :-)) |
| 22:55 | <Domenic> | cabanier: sounds good! glad I could help :) |
| 22:55 | <cabanier> | Domenic: yes, the spec will definitely get better |
| 23:45 | <Hixie> | dreamhost is moving the whatwg.org server to a different back-end to see if that improves performance |
| 23:45 | <Hixie> | site will be down until dns propagates |
| 23:47 | <SamB> | Hixie: why can't they propagate DNS first :-( |
| 23:47 | <Hixie> | because that would just mean the site was down earlier? |
| 23:48 | <SamB> | I mean, er, set up new backend, then wait for dns to propagate, then take down old one. I guess it would be important to flip the wiki to read-only though ... |
| 23:52 | <Hixie> | SamB: not just the wiki |
| 23:52 | <Hixie> | anyway, dns has propagated |
| 23:52 | <SamB> | oh okay |
| 23:53 | <SamB> | I guess a big name like them *would* remeber the "lower TTL first" step |