| 00:14 | <annevk> | Google product login policies make no sense |
| 00:14 | <annevk> | one tab with Gmail and one tab with Google Reader |
| 00:14 | <annevk> | login to Gmail and then refresh Google Reader |
| 00:14 | <annevk> | Google Reader asks for a password |
| 00:15 | <annevk> | going to reader.google.com does not ask for a password |
| 00:15 | <annevk> | you'd think that more people hit this situation and that it would be fixed by now... |
| 01:00 | <othermaciej> | annevk: I would guess that is an implementation bug, not a policy |
| 01:00 | <othermaciej> | unfortunately Google has no way to report bugs |
| 01:05 | <annevk> | btw: http://blogs.webtide.com/gregw/entry/websockets_ietf_v_whatwg |
| 01:06 | <annevk> | I added a comment with a link to http://html5.org/tools/web-apps-tracker?from=3724&to=3725 |
| 01:07 | <annevk> | it also seems somewhat dubious to me to assert that none of "servers, routers, bridges, proxies, firewalls, caches, load balancers, aggregators, offloaders, ISPs, filters, corporate security policies, traffic monitoring, billing, accounting, shaping, application frameworks etc. etc." participates in the WHATWG |
| 01:08 | <annevk> | but whatever |
| 03:07 | <Hixie> | annevk: yeah especially given that the editor of the spec works for the third biggest web server implementor |
| 04:29 | <othermaciej> | annevk: site seems to be down |
| 09:13 | <annevk> | seems to work for me |
| 09:13 | <annevk> | maybe it was down temporarily? |
| 09:13 | <annevk> | still no comments approved though |
| 09:14 | <Hixie> | it was down temporarily |
| 09:18 | <Hixie> | othermaciej: you don't need anything in websocket to do the negotiation of what frame types are supported, because you simply wouldn't use the frame types with an unsupporting server |
| 09:18 | <Hixie> | othermaciej: you know who the server is when you connect to it -- it's the server you specified |
| 09:19 | <othermaciej> | Hixie: how does the server know what frame types the client supports? |
| 09:19 | <Hixie> | othermaciej: it's the same as when you write a <form>, you know what form fields it's expecting, because you know the server |
| 09:19 | <Hixie> | othermaciej: send a frame of that type and see if you get a reply from your script |
| 09:19 | <othermaciej> | Hixie: also: the knowledge of frame types may need to be in the UA, not the JS-level code, if you expect frame types to have special processing and the UA is supposed to send them transparently |
| 09:19 | <Hixie> | othermaciej: or have the script feature-test and inform the server |
| 09:20 | <Hixie> | can you give an example of such a type? |
| 09:20 | <Hixie> | i'm having difficulty working out what that would look like |
| 09:21 | <othermaciej> | let's say there was a frame type that implies gzip compression by the sender and gzip decompression by the client |
| 09:21 | <Hixie> | (don't forget that this is intended to be as close to pure TCP as we can get) |
| 09:21 | <Hixie> | oh, that's easy |
| 09:21 | <othermaciej> | (so that your compression/decompression code could be C++ in the browser, instead of coded in JS) |
| 09:21 | <Hixie> | just include a Supports-Gzip: header in the handshake |
| 09:21 | <othermaciej> | is it ok to add arbitrary headers to the handshake? |
| 09:21 | <Hixie> | yes |
| 09:21 | <Hixie> | er, yes |
| 09:22 | <othermaciej> | then that seems to be all the negotiation mechanism needed |
| 09:22 | <othermaciej> | it might be useful to define a convention for known frame types, but that is not really needed until frame types exist beyond the 1.0 set |
| 09:22 | <Hixie> | indeed |
| 09:23 | <othermaciej> | all I wanted to know is that there is a mechanism whereby the negotiation can be added compatibly, and without extra round trips |
| 09:23 | <othermaciej> | using custom headers seems fine |
| 09:23 | <othermaciej> | especially if we can later define one with a standard meaning |
| 09:24 | <Hixie> | i'm not new to this forwards-compatible language design gig :-P |
| 09:24 | <othermaciej> | Hixie: I am trying to take Greg's feedback seriously, since I care about the protocol being workable and useful for server-side implementors, but he mixes up useful technical feedback with sudden leaps to feature requests, and process rants |
| 09:25 | <othermaciej> | but I'm not new to this peel-the-useful-feedback-out-of-the-rant gig |
| 09:25 | <Hixie> | :-) |
| 09:25 | <Hixie> | i've been trying the same for a while myself |
| 09:25 | <othermaciej> | he actually has tried to implement it in a server-side component that could potentially be production quality |
| 09:26 | <othermaciej> | I wonder if there is any other general implementation besides the Python module that Google coded |
| 09:26 | <Hixie> | of the server? |
| 09:26 | <Hixie> | i made a toy in perl: http://damowmow.com/playground/demos/websocket/blank-server.pl |
| 09:27 | <Hixie> | and another in pascal: http://software.hixie.ch/fun/cuddlyworld/src/websocket.pas |
| 09:28 | <othermaciej> | pascal! |
| 09:28 | <Hixie> | that's what my toy MUD is written in :-) |
| 09:29 | <Hixie> | pascal these days is not what it used to be |
| 09:29 | <Hixie> | it has generics, method pointers, variants, the works |
| 09:30 | <Hixie> | method and operator overloading, classes, reflection |
| 09:31 | <Hixie> | (not to mention a function pointer syntax that actually makes sense, unlike C/C++) |
| 09:37 | gsnedders | wonders whether it's worthwhile getting a week ticket for the public tansport |
| 09:37 | <gsnedders> | (which, because I'm under 20, is only 105 NOK) |
| 09:37 | <Hixie> | othermaciej: other implementations i'm aware of include Kaazing's |
| 09:38 | <Hixie> | othermaciej: also http://rainbows.rubyforge.org/sunshowers/ |
| 09:38 | <annevk> | gsnedders, if you're planning on using it a lot, maybe |
| 09:39 | <gsnedders> | annevk: It's 26 for a single jounrney, so I only need to use it five times for it to be worthwhile |
| 09:39 | <othermaciej> | Hixie: have any of the server implementations generated feedback on the spec? |
| 09:39 | <gsnedders> | Even if I just used it to get to the office each day it's be worthwhile |
| 09:39 | <gsnedders> | *it'd |
| 09:39 | <othermaciej> | (going by the usual rule of "implementation that does not result in any feedback is suspicious" rule) |
| 09:39 | <othermaciej> | Hixie: that is cool though |
| 09:40 | <Hixie> | othermaciej: Kaazing basically invented the protocol as it stands now, if i'm not mistaken |
| 09:40 | <othermaciej> | Hixie: oh, that's the guy who pushed the version with the HTTP-based handshake? |
| 09:40 | <Hixie> | i think so |
| 09:40 | <Hixie> | i can't remember his name though |
| 09:40 | <othermaciej> | Hixie: but I thought you automatically rejected all feedback from server-side developers, since they are not represented in the WHATWG |
| 09:40 | <Hixie> | which is highly embarassing |
| 09:41 | <othermaciej> | I am dismayed at this breach of cabal protocol |
| 09:41 | <Hixie> | othermaciej: well as i pointed out on the list just now... i'm a representative of the third largest HTTP server developer by active domain count |
| 09:41 | <Hixie> | othermaciej: and we wrote an implementation for the biggest one |
| 09:42 | <Hixie> | othermaciej: and i just replied to the feedback from the second biggest |
| 09:42 | <Hixie> | so... |
| 09:42 | <othermaciej> | Hixie: but... but... what about proxy developers? |
| 09:43 | <Hixie> | like squid? had a huge thread with squid a few months ago |
| 09:43 | <Hixie> | took into account their feedback (also rejected a bunch of it, admittedly) |
| 09:45 | <Hixie> | i think the main reason people suggest i'm ignoring feedback is that i don't share the same priorities they do |
| 09:45 | <Hixie> | for grammar, s/i don't share the same priorities they do/we don't share the same priorities/ |
| 09:45 | <Hixie> | i put ease of server-side implementation very high on the list, they put reducing the total number of TCP connections higher |
| 09:46 | <Hixie> | for instance |
| 09:52 | <Hixie> | Michael Carter, that's the Kaazing guy who did the original WebSocket design |
| 09:52 | <Hixie> | great guy |
| 10:09 | <gsnedders> | Lachy: Per what we said before, I'll probably come over to yours sometime between 5 and 7 this evening |
| 10:34 | <Lachy> | gsnedders, ok |
| 10:45 | <annevk> | hmm, is it only Document.URL that has it uppercase? |
| 10:45 | <annevk> | I guess we could change WebSocket/EventSource |
| 10:45 | <annevk> | but then I don't really care |
| 10:46 | <Hixie> | i'd really rather not change names for the sake of capitalisation at this point |
| 10:46 | <annevk> | oh, Stream.URL |
| 10:47 | <annevk> | I still find it wrong we use URNs for this... |
| 10:54 | <Hixie> | me too |
| 10:54 | <Hixie> | it's just going to screw up URNs in the future |
| 10:54 | <Hixie> | it's basically going to make it impossible to use URNs for anything but this in Web browsers |
| 10:55 | <Hixie> | but I have already tried to make that point, and the people who presumably care about URNs didn't believe me, so... not much I can do |
| 10:56 | <annevk> | it mostly that the meaning of the urn:uuid is very application-specific, but there's no way to tell if someone handed you that URL |
| 10:57 | <annevk> | we could register urn:local-file or some such to make it less of an issue but I don't see why filestream: or some such cannot work |
| 10:58 | <Hixie> | ditto |
| 10:58 | <annevk> | btw, should I draft a counter-proposal to UMP once I'm done with other XHR feedback? |
| 10:59 | <annevk> | either create a new AnonXMLHttpRequest() constructor or maybe make XHR take a new constructor argument |
| 11:00 | <annevk> | and then always set origin to null and the credentials flag too |
| 11:00 | <annevk> | othermaciej, ^^ |
| 11:12 | <annevk> | argh |
| 11:12 | <annevk> | making everything in XHR byte-based instead of Unicode-based is a pain |
| 11:13 | <annevk> | not hard |
| 11:13 | <annevk> | just a pain |
| 11:13 | <annevk> | well, it's hard figuring out how to do it easy I guess |
| 11:15 | <annevk> | in retrospect I should've let Hixie do XHR and work more on the CSSOM instead |
| 11:15 | <csarven> | The URI to full whatwg spec is such a trap, if I end-up at it using Firefox, guaranteed chaos/doomed/crash/lockup. |
| 11:15 | <Hixie> | annevk: I'm so glad you took XHR on! |
| 11:20 | <annevk> | basically ASCII case-insensitive and all need to go and be replaced with byte equivalent terms instead |
| 11:20 | <annevk> | though maybe I can just use case-insensitive then |
| 11:21 | <annevk> | just like HTTP does |
| 11:22 | <annevk> | it's actually slightly weird imo that HTTP uses case-insensitive and case-sensitive while the same WG also states that the character encoding in usage is not defined |
| 11:22 | <annevk> | or some such |
| 11:22 | <annevk> | but maybe case-insensitive "just works" for series of octets |
| 11:29 | annevk | wonders why http://www.defectivebydesign.org/shareipad does not have a share on twitter button... |
| 12:32 | <annevk> | sites using Flash was a real problem when trying to find more information about certain hostels online in Argentina by the way |
| 12:33 | <annevk> | basically, we ended up picking one of the hostels of which the site did not require Flash |
| 12:34 | <annevk> | threaded view in Opera Mail is now just like Gmail except faster |
| 12:34 | <annevk> | pretty neat |
| 12:35 | annevk | had been using a flat view until trying to go through 4000 emails efficiently |
| 12:51 | <Dashiva> | Does it support multiple accounts yet? |
| 12:51 | <annevk> | character to byte conversion is complete btw; please review! |
| 12:52 | <annevk> | Dashiva, you mean something other than multiple IMAP accounts on the server? |
| 12:53 | <Dashiva> | Multiple SMTP accounts |
| 12:53 | <Dashiva> | Or more accurately, multiple sending addresses |
| 12:55 | <annevk> | there's a from dropdown when composing |
| 12:55 | <annevk> | no idea whether it works |
| 12:57 | <Dashiva> | Sounds like the old system |
| 12:59 | <Dashiva> | It breaks sent mail saving and such |
| 13:17 | <annevk> | damn video codecs |
| 13:51 | <Dashiva> | http://twitter.com/reckless/status/8431718270 |
| 13:57 | <virtuelv> | Dashiva: I don't get his argument |
| 13:57 | <virtuelv> | at all |
| 14:03 | <Dashiva> | virtuelv: In response to the claim that the number of flash-enabled UAs is dropping |
| 14:08 | <virtuelv> | yes |
| 14:08 | <virtuelv> | but it still doesn't make sense |
| 14:09 | <virtuelv> | the reason people use flashblock and similar is because there are sites that break (read: youtube) if they rid themselves of flash |
| 14:10 | <Dashiva> | There are plenty of sites that don't break without flash, though |
| 14:11 | <Steve^> | and plenty that do |
| 14:11 | <Steve^> | So either you block the crappy ones and have a full browsing experience or uninstall flash and have a 90% experience |
| 14:12 | <Dashiva> | That's the point. Flash is part of the full browsing experience. |
| 14:12 | <Steve^> | so.. we need flash installed? |
| 14:13 | <Dashiva> | That depends on your definition of need |
| 14:13 | <Steve^> | and your definition of browsing experience, apparently |
| 14:14 | <Dashiva> | You don't need flash to browse in general, but you need flash to browse sites that use flash |
| 14:14 | <Steve^> | exactly |
| 14:14 | <Steve^> | so you need flash to browse the full experience of the web |
| 14:14 | <Steve^> | Youtube is included in that |
| 14:18 | <annevk> | not anymore |
| 14:18 | <Steve^> | ok, ok, but the statement holds |
| 14:18 | <Dashiva> | Unless you use firefox :) |
| 14:20 | <Steve^> | Would it be impossible for firefox to use H.264 because of the licensing? |
| 14:21 | <Dashiva> | Yes, no, depending on ideology |
| 14:21 | <GarethAdams|Home> | it would *cost* firefox to use H.264 - in the same way as it does for Chrome/Opera |
| 14:22 | <GarethAdams|Home> | but then it should also cost content providers who encode in H.264 |
| 14:22 | <TabAtkins> | And, iirc, it will, starting sometime next year? |
| 14:22 | <Dashiva> | There are also problems with using OS-provided codecs, although people disagree on how signficant those are |
| 14:23 | <Steve^> | Who does the money go to/ |
| 14:23 | <TabAtkins> | MPEGLA |
| 14:24 | <Steve^> | why do Apple want to push a technology that mean its content providers need to pay money to those people |
| 14:24 | <Dashiva> | Because they've already paid for h264 |
| 14:24 | <Steve^> | Apple have |
| 14:25 | <Steve^> | but by content providers, I read Youtube or anyone hosting video on their website |
| 14:25 | <virtuelv> | in terms of flash, though: I see mostly only flash I want to see, but then again, I block graphical ads |
| 14:25 | <TabAtkins> | Because they're short-sighted, imo. |
| 14:25 | <Dashiva> | Apple also has a strong interest in devices, where hardware h264 is already established |
| 14:25 | <virtuelv> | and it's not the flash I want to see, rather the video |
| 14:25 | <TabAtkins> | (I agree fully with ROC's view on the matter.) |
| 14:25 | <Steve^> | Long term I'll need to pay money to put home-made videos on my website? |
| 14:26 | <TabAtkins> | In h.264, likely yes. |
| 14:26 | <Steve^> | That will just empower flash to keep going, surely |
| 14:26 | <Dashiva> | Well, you can't create really flash for free either |
| 14:26 | Dashiva | moves the 'really' over a few words |
| 14:27 | <GarethAdams|Home> | lol |
| 14:27 | <Dashiva> | Take youtube, the whole h264 business is hidden from the content creators |
| 14:31 | <virtuelv> | Dashiva: what about when the cost won't be hidden? |
| 14:31 | <Dashiva> | Then it won't matter much if they're using h264 inside or outside of flash, will it? |
| 14:32 | <Steve^> | I take Youtube to be the content provider, the uploader wouldn't be charged unless Youtube decided to pass on the costs |
| 14:33 | <Steve^> | which may become a way for Youtube to become more profitable |
| 14:34 | <Dashiva> | Would mean waving goodbye to the long tail, though |
| 14:37 | <virtuelv> | btw, for web video, I don't really get the quality argument |
| 14:38 | <virtuelv> | the quality of the majority of uploaded video is so abysmal anyhow that a slightly lower-quality codec won't matter |
| 14:39 | <Dashiva> | Quality isn't an absolute, it's a trade-off against size. Better codecs let you optimize in either direction |
| 14:39 | <Philip`> | Also a tradeoff against encoding time |
| 14:39 | <GarethAdams|Home> | virtuelv: I don't get *that* argument |
| 14:39 | <GarethAdams|Home> | virtuelv: you're saying, cameraphones make rubbish quality video so we should standardise on a solution that stops production-quality video from being shown off at full quality? |
| 14:40 | <Dashiva> | Philip`: Encoding is only once, though |
| 14:40 | <Philip`> | Also the quality of the codec is not the only major factor, the quality of the encoder implementation is pretty important too |
| 14:41 | <Philip`> | and popular codecs have more and better encoders, so you can get better videos even if the codec is technically no better than another |
| 14:41 | <Steve^> | Does OGG violate any of these factors? |
| 14:41 | <Dashiva> | No |
| 14:43 | <Dashiva> | Theora's main lack is that h264 has an established position, e.g. in the form of companies already paying for it and exposing patent risk, and in the form of hardware support |
| 14:43 | <Dashiva> | The squabbling over quality is less important, for reasons Philip` pointed out |
| 14:43 | <Philip`> | Dashiva: If you're someone like Youtube and you have a day of videos to encode per minute, I imagine the overall encoding time is an issue |
| 14:43 | <Philip`> | and if you're a user of Youtube then the latency of encoding is important, because you want to point people at your video as quickly as possible |
| 14:43 | <Steve^> | Hardware support shouldn't be an issue for Apple as they control the hardware they use |
| 14:44 | <Dashiva> | Philip`: Those seem lesser concerns than bottom line costs and profits, though |
| 14:44 | <Steve^> | It would be an issue for say, Opera Mini, which has a very large target hardware |
| 14:44 | <Philip`> | and if you're encoding and hosting videos by yourself then you probably still don't fancy spending an hour compressing your videos with really good compression before uploading them |
| 14:46 | <Philip`> | Dashiva: Isn't the cost basically CPU time + storage + bandwidth, so encoding time is an important part of that concern? |
| 14:46 | <Steve^> | Philip`, it is of course a concern, but not has important as the others |
| 14:46 | <Philip`> | (and most videos are viewed approximately zero times so bandwidth is negligible) |
| 14:47 | <Dashiva> | I wonder what the stats on that actually are |
| 14:48 | <Dashiva> | And it's easier to grow server CPU time than it is to grow the end user's bandwidth :) |
| 14:53 | <Philip`> | Fig 7 in http://www.cs.sfu.ca/~jcliu/Papers/YouTube-IWQoS2008.pdf indicates some numbers |
| 14:53 | <Philip`> | Looks like 50% have <400 views |
| 14:54 | <Philip`> | and 90% have <10000 |
| 14:54 | <Steve^> | that's more than 0 |
| 14:55 | <Philip`> | (in 2007) |
| 14:56 | <Steve^> | this argument is a little pointless unless a competing video codec happens to have terrible encoding times |
| 14:56 | <Philip`> | (Seems quite possible that their data collection method is biased towards more popular videos, given how they crawled the site) |
| 14:56 | <Philip`> | Steve^: Not a lot more than 0 :-) |
| 14:57 | <Philip`> | Well, maybe a bit |
| 15:02 | <TabAtkins> | Steve^: From what I understand, Google is happy with Youtube's current profitability. |
| 15:03 | <Philip`> | TabAtkins: You mean its current lack of profitability? :-) |
| 15:04 | <TabAtkins> | All I know is, last article I read where they were asked about it, they coyly suggested that it wasn't *nearly* as unprofitable as everyone assumes. |
| 15:10 | <Dashiva> | Completely differently unprofitable |
| 15:18 | <Philip`> | (Hmm, if I actually look at numbers instead of guessing, it seems like encoder CPU time and disk storage are about equally cheap, and bandwidth is around a thousand times higher, to within a couple of orders of magnitude) |
| 20:04 | <Dashiva> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=8850 |
| 20:05 | <Dashiva> | Just when you thought it was safe to focus on technical details... |
| 20:06 | <annevk> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849 is interesting |
| 20:46 | <TabAtkins> | annevk: A better variant of that idea would be to allow @sandbox on <html>, but that's already been suggested to be possible on any element - it fails open in legacy clients, though. |
| 20:47 | <TabAtkins> | At least, though, the escaping situation is less dire if you don't do it right - worst case the page will end prematurely because an attacker emitted </html>. |
| 20:48 | <Philip`> | <plaintext sandbox> |
| 20:48 | <Philip`> | That'll have safe legacy behaviour |
| 20:49 | <TabAtkins> | Once you do that, though, what's the point of @sandbox? |
| 20:49 | <TabAtkins> | <plaintext> prevents the <script> from running anyway. |
| 20:50 | <Philip`> | In supporting browsers it would parse the context as sandboxed HTML instead |
| 20:51 | <TabAtkins> | ...that makes sense. Hmm. |
| 20:52 | <Dashiva> | How about just serving text/html-sandboxed? |
| 20:52 | <TabAtkins> | That doesn't let you specify which sandboxing behaviors you want. |
| 20:53 | <TabAtkins> | Though, of course, if you then do <html sandbox>... |
| 20:53 | <TabAtkins> | That is, if you do that and serve it with text/html-sandboxed. |
| 20:53 | <TabAtkins> | That seems like a good idea. |
| 20:57 | <Philip`> | No point making it so complex that people won't bother using it |
| 20:57 | <TabAtkins> | I've added a comment to the bug along those lines. |
| 20:57 | <TabAtkins> | No more complex than iframe sandboxing. |
| 20:57 | <Philip`> | Does <iframe sandbox src> require that the content is text/html-sandboxed? |
| 20:57 | <TabAtkins> | No, it doesn't require it. It'll just fail open if you don't. Same thing here. |
| 20:57 | <annevk> | it wouldn't fail for cross-origin |
| 20:58 | <annevk> | at some point we might need a global script language switch |
| 20:58 | <TabAtkins> | Well, partially. You'd get the different-origin protection, at least. |
| 20:58 | <Philip`> | I guess it'll be common for people to either forget to set the content-type at all, or to accidentally set it back to text/html later when they're not paying attention, which wouldn't be much fun |
| 20:59 | <Philip`> | (and they wouldn't notice until someone exploited it) |
| 20:59 | <TabAtkins> | Shrug. The alternative is encoding the content in such a way so that it can't be interpreted as html at all by legacy clients. |
| 21:00 | <TabAtkins> | At least it's a problem that will go away with time. |
| 21:00 | <TabAtkins> | (As legacy clients drop off.) |
| 21:16 | <annevk> | hmm, trying to figure out when enableStyleSheetsForSet was renamed in Mozilla is somewhat of a pain with Bugzilla not giving me answers and HG Blame not going back to when CVS was still used |
| 21:18 | <annevk> | oh, it never was renamed |
| 21:18 | <annevk> | hmm |
| 21:20 | <annevk> | I guess it must have been a private email conversation back then |
| 21:21 | <annevk> | oh well, it does not matter, history will record it as a typo I made |
| 21:27 | <Philip`> | If you didn't find it already: CVS blame still exists and works, for the pre-Hg code |
| 21:28 | <annevk> | yeah, found it when looking a little longer |
| 22:10 | <smaug___> | annevk: to look for changes in mozilla tree before hg time, use http://mxr.mozilla.org/seamonkey/ or http://mxr-test.konigsberg.mozilla.org/ |
| 22:10 | <smaug___> | the latter one has links to both hg and cvs |
| 22:11 | <annevk> | thanks, already found what I needed |
| 23:59 | <annevk> | smaug___, note that <h1><h2> may be relevant because <h2> closes <h1> |
| 23:59 | <annevk> | iirc |
| 23:59 | <annevk> | smaug___, so you want to use <div> instead if you were to actually use that in example code |