| 00:00 | <Hixie> | personally i think the whole splitting spec thing is a waste of time and woul rather we went back to complete.html, but i'm trying to find solutions that work for the htmlwg members |
| 00:02 | <othermaciej> | indeed, I see you have made a solomonic effort |
| 00:02 | <othermaciej> | the intro seems to relate most to either the core or vocabulary specs, not really sure which |
| 00:06 | <othermaciej> | core vs. vocabulary ended up kind of a wacky split, since core defines parts of the vocabulary |
| 00:06 | <JonathanNeal> | I just wanted to know the name of one WYSIWYG editor that supports new HTML5 elements. CKEditor moves them around like ragdolls and TinyMCE seems to replace them with other elements. |
| 00:08 | <zcorpan__> | JonathanNeal: why would you want to handle the new elements with wysiwyg rather than in handwritten templates? |
| 00:08 | <cardona507> | hixie - hello - am working on some graphics for <meter> and I am wondering if user agents will always show it as a small bar with part of it colored in similar to the usenet example that is live in the spec? Or will it sometimes be rendered as a clock other times a thermometer other times a bar etc depending on the situation? |
| 00:08 | <JonathanNeal> | zcorpan__, there may be instances where I want to create my own section or articles within one inside the wysiwyg |
| 00:12 | <zcorpan__> | JonathanNeal: for section, you can use implied section by just using a heading. for article.. why would you want to have a nested article in wysiwyg? |
| 00:13 | <JonathanNeal> | zcorpan__, while I don't mind getting into those details, they detract from the fact that all new html5 elements fail in the most well known wysiwyg editors and I was wondering if that was a limitation of the browser or the wysiwyg. |
| 00:15 | <zcorpan__> | ok. my guess is that the wysiwyg could support them even though they're not known elements in the browser |
| 00:16 | <zcorpan__> | and even if they're known elements in the browser, they'd still fail in existing editors |
| 00:17 | <JonathanNeal> | ok. i checked a few months ago and no one had tried html5 in a wysiwyg then either. |
| 00:17 | <zcorpan__> | maybe you could try implementing it yourself :) |
| 00:18 | <JonathanNeal> | I did, a few months ago. |
| 00:18 | <zcorpan__> | oh cool |
| 00:18 | <JonathanNeal> | I created various work-arounds that worked enough for us to push to our new site. |
| 00:18 | <JonathanNeal> | Problem is our product is kinda like a cms. |
| 00:18 | <JonathanNeal> | So when they hear our new site is HTML5, they think they can just make HTML5 sites with our product. |
| 00:19 | <JonathanNeal> | And all the support questions are coming to me because I did it, but I'm saying "I hacked the thing up to the point where it works because it ignores the elements in the wysiwyg, because it still does not support them" --- that made me think of pinging this chan again :D |
| 00:21 | <zcorpan__> | maybe you could file requests for proper html5 support in popular editors |
| 00:23 | <JonathanNeal> | Yea, I've seen it and seen it ignored, but I'll make some noise. |
| 00:51 | <cardona507> | any feedback on this for <meter> http://img46.imageshack.us/img46/3571/whatwgmeterex101.png ? |
| 00:52 | <cardona507> | I am also creating a thermometer |
| 00:52 | <Hixie> | nice |
| 00:53 | <Hixie> | uh the number of notches on that dial makes no sense :-) |
| 00:53 | <Hixie> | you have four in the first bit and three for the rest :-) |
| 00:53 | <Hixie> | should be four each time if it's a decimal dial |
| 00:53 | <cardona507> | doh :) hehe |
| 00:53 | <cardona507> | yeah - that was the intention :) |
| 00:53 | <cardona507> | hehe - i'll fix that real quick |
| 00:53 | <Hixie> | :-) |
| 01:07 | <Hixie> | ok <details> is back |
| 01:08 | <cardona507> | ok - I fixed the notches on the dial - http://img132.imageshack.us/img132/3571/whatwgmeterex101.png |
| 01:10 | <Hixie> | nice |
| 01:12 | <cardona507> | thanks |
| 01:12 | <daedb> | Nice to see <details> back... there is still hope :) |
| 01:12 | <Hixie> | this is #whatwg, so technically <details> never left :-P |
| 01:12 | <Hixie> | it only briefly was out of the w3c version of the spec |
| 01:12 | <Hixie> | never left the whatwg one |
| 01:14 | <daedb> | True, but I want both versions to be nice, not just the Whatwg one ;-p |
| 01:14 | <Hixie> | well with the splits and stuff the w3c one is no longer nice :-( |
| 01:16 | <daedb> | I don't understand the split out "core" spec... it doesn't contain the elements and syntax sections? I don't get how those are not part of the core of the language... |
| 01:18 | <Hixie> | see http://www.w3.org/Bugs/Public/show_bug.cgi?id=8365 for the reasoning |
| 01:18 | <Hixie> | i agree that it doesn't make much sense, i'm just trying to address the bugs that are filed according to the htmlwg process |
| 01:18 | <othermaciej> | I understand some of the motivation for the split but I'm not sure it ended up sensible |
| 01:19 | <cardona507> | so the new elements aren't in the "core" spec? |
| 01:19 | <othermaciej> | none of the elements are in the "core" spec (although a few attributes are) |
| 01:20 | <cardona507> | gotcha |
| 01:20 | <cardona507> | alot of specs |
| 01:21 | <othermaciej> | also, while I don't personally care much how many different documents there area, the resulting broken cross-references make some things hard to follow |
| 01:21 | <Hixie> | the attributes in the "core" spec are there because shelley didn't want "hidden" in the vocabulary spec, and it seemed the others were thematically related so i figured i should move them all together |
| 01:36 | <cardona507> | How about this for <meter> http://img262.imageshack.us/img262/434/whatwgmeterex201.png ? |
| 01:37 | <cardona507> | hehe - expect the C would say 50 at the bottom :) |
| 01:38 | <cardona507> | like this http://img23.imageshack.us/img23/434/whatwgmeterex201.png |
| 01:43 | <Hixie> | interesting, though i'm not sure a browser would ever be that specific, since it doesn't really know it's a temperature gauge from the markup... |
| 01:43 | <Hixie> | maybe that would be better as an xbl2 example |
| 01:44 | <Hixie> | (as a <meter> binding) |
| 01:45 | <cardona507> | what examples can you image a browser implementing? |
| 01:46 | <cardona507> | for example the one from the spec that talks about a tooltip appearing that says "23 seconds" - should I create that as a digital clock face? |
| 01:46 | <cardona507> | and have a mouse pointer and tooltip of course |
| 01:50 | <Hixie> | i think gauges are more likely to be generic things like simple bars |
| 01:52 | <Hixie> | mac os x has some built-in indicators that might give some inspiration |
| 01:52 | <Hixie> | gotta go cook dinner, bbiab |
| 02:17 | <cardona507> | web applications 1.0 - wow |
| 02:21 | <cardona507> | the kitchen sink - heh |
| 02:42 | Philip` | wonders if it's possible to have a kitchen sink, or if instead it would float |
| 02:43 | <cardona507> | thats a question for #css :) |
| 06:37 | <Lachy> | Hixie, these new spec splits seem crazy. WTF? |
| 06:38 | <Lachy> | can't we come up with a way to keep everything in the same spec, but perhaps more cleanly divided into Core and Vocabulary sections, and have that distinction clearly reflected in the ordering of sections and splitting of the multi-page doc. |
| 06:58 | <Lachy> | Hixie, "the attributes in the "core" spec are there because shelley didn't want "hidden" in the vocabulary spec..." - that's the most illogical and irrational justification ever. |
| 06:58 | <Lachy> | So just because Shelley wants something, you do it now? WTF?! |
| 07:25 | <hsivonen> | at least it looks like the <details> removal didn't last for long |
| 07:47 | Dashiva | ponders if gauge could be used by simply aliasing all the common misspellings to be the same element |
| 07:48 | <Hixie> | heh |
| 07:48 | <Hixie> | not an impossible idea |
| 07:48 | <Hixie> | doesn't work for xml though |
| 07:48 | <Hixie> | or createElement() |
| 07:51 | <Dashiva> | XML assumes competent authors in the first place, surely competent enough to use spell checking. createElement is problematic, though :) |
| 07:52 | <Hixie> | dude i can't spell gauge to save my life |
| 07:52 | <Hixie> | i typo it 9 times out of 10 |
| 07:52 | <Lachy> | no, let's not repeat the same mistake with <image> |
| 07:52 | <Hixie> | it's not like i don't know how to spell it |
| 07:52 | <Hixie> | i just always get it wrong |
| 07:53 | <Hixie> | and if "<script langauje=''>" is anything to go by, i am by far not the exception |
| 07:54 | <Dashiva> | That's an invisible and harmless typo, though |
| 07:54 | <Hixie> | the problem isn't people not catching it |
| 07:54 | <Hixie> | the problem is people wasting time making the mistake in the first place |
| 07:57 | <hsivonen> | I find it weird that people find gauge hard to spell |
| 07:58 | <Hixie> | i find it easy to spell, hard to type |
| 07:58 | <hsivonen> | probably because I think of it by pronouncing it in Finnish in my mind, which makes the spelling unambiguous |
| 07:58 | <hsivonen> | oh |
| 08:01 | <Dashiva> | Features defined in a very large |
| 08:01 | <Dashiva> | spec, like SVG 1.2 Tiny |
| 08:01 | <Dashiva> | If Tiny is "very large", what is the full SVG spec? :) |
| 08:02 | <Hixie> | tiny is almost as large as html5 |
| 08:11 | <hsivonen> | should Tiny be split?!? ;-) |
| 08:12 | <Hixie> | imho no, though "full" should be dropped :-) |
| 08:14 | <hsivonen> | I think aspects of Tiny (xml:id, XML Events, textArea) should be dropped, too |
| 08:15 | <Hixie> | yes |
| 08:58 | <Hixie> | can anyone figure out a succint way of presenting http://www.whatwg.org/specs/diagram.html ? |
| 09:01 | <Dashiva> | How about just listing each one (not WA 1.0), and then having a note "There's also a combined view of all the active specs <WA 1.0>" |
| 09:05 | <Hixie> | that doesn't really handle the HTML part (click the button), nor the Web SQL bit (at the bottom) |
| 09:10 | Hixie | ponders taking out the Web Apps 1.0 column in lachy's table, and replacing it with a single link below |
| 09:10 | <Hixie> | i don't know that we want to encourage that view |
| 09:12 | <Hixie> | Lachy: any opinion? |
| 09:12 | <Lachy> | Hixie, why not? |
| 09:13 | <Lachy> | that version of the spec is the best |
| 09:13 | <Lachy> | also, I think presenting that diagram as a simple tree structure is easiest: |
| 09:13 | <Lachy> | WHATWG Work |
| 09:13 | <Lachy> | +- Web Applications 1.0 |
| 09:13 | <Lachy> | | | |
| 09:13 | <Lachy> | | +- WHATWG HTML |
| 09:13 | <Lachy> | | | | |
| 09:13 | <Lachy> | | | +- HTML5 (W3C) |
| 09:13 | <Lachy> | | | +- Microdata |
| 09:13 | <Lachy> | | | +- 2D Context |
| 09:13 | <Lachy> | | | +- HTML Device |
| 09:13 | <Lachy> | | | |
| 09:13 | <Lachy> | | +- Web Workers |
| 09:13 | <Lachy> | | +- Web Storage |
| 09:13 | <Lachy> | | +- Web Sockets API |
| 09:13 | <Lachy> | | +- Web Sockets Protocol |
| 09:13 | <Lachy> | | +- Server-sent Events |
| 09:13 | <Lachy> | | |
| 09:13 | <Lachy> | + Web SQL Database |
| 09:14 | <Lachy> | Or maybe you could do it as a venn-diagram or something |
| 09:14 | <Hixie> | venn diagram would be a bitch to maintain |
| 09:14 | <Hixie> | as i'm sure we'll be seeing more splits in the near future |
| 09:14 | <Lachy> | NOOOOOOO!!!! |
| 09:15 | <Lachy> | Seriously, no more spec splits. Please. |
| 09:15 | <Lachy> | splitting specs makes it difficult to figure out where to look to find something specific. |
| 09:16 | <Hixie> | i'm not planning any in particular, it just seems likely to happen given that we've had one issue resolved and it's resulted in a split |
| 09:16 | <Lachy> | e.g. Today, when looking through the proposed core and vocab splits, it took me a while to figure out where the Parsing section would be, since I intuitively thought it would be in Core |
| 09:17 | <Lachy> | I thought Vocab would be basically section 4, plus other elements and attributes scattered throughout a few other sections |
| 09:18 | <Lachy> | anyway, what's your reason for not wanting to encourage the Web Apps 1.0 spec? |
| 09:19 | <Hixie> | dunno, hadn't really thought about it |
| 09:19 | <Hixie> | i figured it was just something i liked and maybe 2 or 3 other people and everyone else hated it |
| 09:19 | <Hixie> | certainly it's unpopular in w3c circles |
| 09:21 | <Lachy> | within W3C circles, just about everything in HTML5 is unpopular with some groups of people. |
| 09:22 | <Hixie> | man i hate wiki syntax |
| 09:22 | <Lachy> | initially I hated the complete version, cause the annotation script really killed my browser. But since blocking that script, it works just fine and I use it all the time |
| 09:22 | <Lachy> | I think it might possible to use regular HTML syntax for tables in mediawiki |
| 09:22 | <Lachy> | so feel free to change it if you like |
| 09:25 | <Hixie> | it's more that it is presentational |
| 09:26 | <Hixie> | (the markup, not the table) |
| 09:29 | <Lachy> | my problem with wiki markup is that it uses an odd mix of HTML and custom non-intuitive syntax |
| 09:31 | <Dashiva> | It is |
| 09:32 | <Dashiva> | But it would be even worse if every single part of HTML was reinvented in wiki markup, IMO |
| 09:32 | <Hixie> | i just don't understand the need for a new language in the first place |
| 09:34 | <Lachy> | probably because people find editing HTML to be quite verbose, and the limited editing facilities provided by a textarea in a web page aren't really ideal |
| 09:36 | <Hixie> | Lachy: what do you think of http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F now? |
| 09:36 | <Hixie> | i tried to make it tidier |
| 09:38 | <Dashiva> | If you explained Web Applications 1.0 outside the table, you could instead make the WA column "Location in WA 1.0", and the WHATWG specs column would be less wide and bulky |
| 09:44 | <Hixie> | i made the column narrower |
| 09:44 | <Hixie> | not sure how to really explain the wa1 spec without scaring people :-) |
| 09:46 | <Dashiva> | By the way, mediawiki tables look much nicer with border=1 cellpadding=3 cellspacing=0 (at least I think so) :) |
| 09:46 | <Hixie> | have mediawiki devs not heard of css? :-) |
| 09:46 | <hsivonen> | what's the diff between current-work/ and complete.html? |
| 09:46 | hsivonen | always read current-work/ |
| 09:47 | <Dashiva> | You can use CSS too |
| 09:47 | <Hixie> | complete.html includes all the webapps specs |
| 09:47 | <Hixie> | Dashiva: i mean, why don't they jsut have some classes that make these tables actually pretty |
| 09:47 | <hsivonen> | ok |
| 09:48 | <Dashiva> | AryehGregor might know |
| 09:49 | <hsivonen> | maybe mediawiki is supposed to support old IE |
| 09:50 | <Dashiva> | "All active work at WHATWG is gathered in the Web Applications 1.0 document, available in <links>. For the HTML-specific work only, see WHATWG HTML at <links>. Individual specifications are also available, see the following table." |
| 09:51 | <Hixie> | feel free to edit the table, i closed the tab :-) |
| 09:54 | <hsivonen> | I think the WHATWG needs a page with links to all the specs that are part of the canonical platform |
| 09:54 | <hsivonen> | including a table-based visualization on overlapped specs |
| 09:55 | <hsivonen> | whether the overlap is WHATWG vs. W3C or IETF |
| 09:55 | <hsivonen> | or CSS 2.1 vs. CSS3 |
| 10:07 | <Hixie> | write one and put it on the blog :-) |
| 10:08 | <hsivonen> | Hixie: I'd get accused of Webmandering again |
| 10:09 | <Hixie> | people accuse people of that? |
| 10:09 | <hsivonen> | http://schepers.cc/?p=117 |
| 10:16 | <hsivonen> | oh. jd has showed up in the blog comments |
| 10:24 | <hsivonen> | I intend the post a descriptive view of the platform some time based on the collectively edited W3C spec browser impl score card |
| 10:29 | <Dashiva> | Amusing the 'multi-page' link for Microdata links to the single page microdata.html, whereas 'single-page' links to all of WHATWG HTML :) |
| 10:36 | <Dashiva> | http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F |
| 10:36 | <hsivonen> | it's very confusing to have this many spec vieews |
| 10:37 | <hsivonen> | it would be clearer to have tiny bits and complete |
| 10:37 | <Hixie> | heh, i hadn't seen http://hsivonen.iki.fi/web-stack/ before |
| 10:37 | <hsivonen> | but the intermediate collections seem confusing |
| 10:37 | <Hixie> | here's mine: http://www.whatwg.org/specs/web-apps/current-work/images/abstract.png |
| 10:37 | <Dashiva> | There's only one, isn't there? |
| 10:38 | <hsivonen> | Dashiva: I've lost track how many intermediate collections there are |
| 10:38 | <Dashiva> | WHATWG HTML is "the" spec, WA 1.0 is more like a rendered view of complete |
| 10:38 | <Hixie> | Dashiva: i think i preferred it with the WHATWG HTML line in the table |
| 10:39 | <Hixie> | when you look at the answer you just naturally assume the table is complete |
| 10:39 | <hsivonen> | Hixie: the material of the sink makes it look like a bathroom sink rather than a kitchen sink |
| 10:39 | <Hixie> | whereas now it's omitting the two main links |
| 10:39 | <Hixie> | hsivonen: yeah, well, it was the best i could find on short notice :-P |
| 10:40 | <Dashiva> | Hixie: I was thinking like hsivonen, that it would be better to have a clear separation between individual specs and compilations |
| 10:40 | <Dashiva> | But by all means, it's a wiki :) |
| 10:44 | <Hixie> | the idea of that section is really to answer the question "what should i be reading" |
| 10:45 | <Hixie> | Dashiva: i like the split into two questions though |
| 10:45 | <Hixie> | anyway i really should go to bed |
| 10:54 | <Hixie> | hsivonen: btw original picture was http://www.flickr.com/photos/wonderlane/2986252088/ |
| 10:56 | <Lachy> | ah, I finally got my internet connection back. That was annoying. ISP troubles, I guess. |
| 10:57 | <Lachy> | Hixie, the spec table in the FAQ looks good now. |
| 10:57 | <Hixie> | the most recent changes were mostly Dashiva's work :-) |
| 10:57 | <Hixie> | i might add the WHATWG HTML line back in tomorrow, we'll se |
| 10:57 | <Hixie> | e |
| 11:03 | <Lachy> | Dashiva, why did you decide to take out the _in Single-page_ links here? http://wiki.whatwg.org/index.php?title=FAQ&diff=next&oldid=4340 They seemed useful |
| 11:05 | <hsivonen> | http://twitter.com/adactio/status/7527318716 |
| 11:05 | <Dashiva> | Lachy: I figured that if someone wants to see a specific specification, they wouldn't want to load all the other stuff in WHATWG HTML |
| 11:06 | <Dashiva> | (Also, I couldn't find a good way to include them both without either too much text or vague link names) |
| 11:09 | <Lachy> | ok |
| 11:12 | <Hixie> | i like how in http://lists.w3.org/Archives/Public/public-html/2010Jan/0192.html shelley refers to a message about "postmessage and localstorage" that i supposedly sent, and goes on to criticise me for mentioning localstorage... when the message in question, which she quotes in the very same e-mail, doesn't mention localstorage |
| 11:12 | <Hixie> | (i only references onhashchange and postmessage, both in html5) |
| 11:12 | <Hixie> | referenced, even |
| 11:15 | <Lachy> | haha |
| 11:20 | <Lachy> | Hixie, shouldn't this bug now be resolved WONTFIX and Rejected, or at least reopened as it's no longer resolved as stated? http://www.w3.org/Bugs/Public/show_bug.cgi?id=8118 |
| 11:22 | <Hixie> | reopened it |
| 11:24 | <Hixie> | nn |
| 11:24 | <Lachy> | so Julian thinks discussion changes in the WG's bug tracker is not an appropriate place to discuss spec changes? http://lists.w3.org/Archives/Public/public-html/2010Jan/0340.html |
| 11:25 | <alfa> | Does all the ridiculousness in the W3C HTML WG have the potential to delay browser implementations of new features? |
| 11:34 | <Dashiva> | alfa: To a certain degree, by consuming time and effort that could go to developing a better spec |
| 11:35 | <hsivonen> | Dashiva: ...and writing code |
| 11:46 | <Philip`> | Someone should make a concise summary of all the complaints people make, so when two people make conflicting complaints (e.g. the spec is too monolithic, the spec is too fragmented; discussion should be in bugs, discussion should be on the list; etc) we can point them at each other to resolve their differences themselves |
| 11:47 | <Philip`> | without dragging in any more people to the discussion than is necessary |
| 12:16 | <alfa> | davisha: ok, i was concerned that the current situation might cause FUD to make implementors consciously "wait and see" |
| 12:23 | <hsivonen> | alfa: it could. too early to tell |
| 12:28 | <Dashiva> | For some reason, my nick seems to be up there with gauge on spellability |
| 12:29 | <alfa> | dashiva: my apologies :) |
| 15:17 | <mikekelly> | hi fans |
| 15:18 | <mikekelly> | what's the barrier to standardizing a javascript API for setting/flushing Authorization header (per domain) ? |
| 15:19 | <mikekelly> | obviously this is outside of HTML or HTTP - this is more just a general question aimed at browser people =) |
| 15:19 | <Philip`> | Why should it be a JS API? |
| 15:19 | <mikekelly> | why is XHR js? |
| 15:19 | <mikekelly> | :/ |
| 15:19 | <Philip`> | Because the purpose of XHR is to let JS make HTTP requests, so it has to be JS |
| 15:20 | <mikekelly> | well this is to let JS set the Authorization header.. |
| 15:20 | <Philip`> | Authorization seems to be a purely HTTP thing |
| 15:20 | <mikekelly> | what? |
| 15:20 | <Philip`> | (currently) |
| 15:20 | <mikekelly> | what does that even mean |
| 15:20 | <mikekelly> | :/ |
| 15:21 | <mikekelly> | so you can't understand what one might want to set Authorization header for a browser session? |
| 15:21 | <mikekelly> | with js |
| 15:21 | <Philip`> | I just mean there isn't currently a JS interface to any part of it, as far as I'm aware |
| 15:21 | <mikekelly> | right - I'm asking what the barrier is to that kind of API |
| 15:21 | <mikekelly> | where access is simply set/flush the header |
| 15:22 | <mikekelly> | and browser persists this per domain the same way it does for HTTP Basic right now.. |
| 15:22 | <mikekelly> | but also exposes flush so we can actually implement logout.. |
| 15:22 | <Philip`> | Probably the main problem is to convince people that a JS interface is better than any other ways of making authorization more useful (e.g. allowing custom HTML login forms, adding something to HTTP for logout pages, etc) |
| 15:22 | <mikekelly> | that's not how HTTP Authorization works |
| 15:23 | <mikekelly> | Logging In is a client-side state change |
| 15:23 | <mikekelly> | it's outside the scope of HTTP |
| 15:23 | <mikekelly> | whether the client is required to resubmit the Auth credentials for every request.. or they are persisted.. is down to the client |
| 15:23 | <mikekelly> | HTTP is completely agnostic to that |
| 15:24 | Philip` | sees a site that does <div class="FloatLeft VerdanaText Bold Font-Size-12 Margin-Top-4 Margin-Left-5 AlignCenter" style="width: 190px; height: 15px;" > |
| 15:24 | <mikekelly> | if browser provided a JS API for set/flush the header per domain this functionality could be controlled via HTML+js |
| 15:24 | <Philip`> | Hooray for separation of presentation and content |
| 15:25 | <mikekelly> | ? |
| 15:25 | <mikekelly> | =/ |
| 15:25 | <Philip`> | mikekelly: Maybe it'd be something that's useful - I guess you should write a proposal and see if anyone's interested |
| 15:26 | <Philip`> | (That was an aside, not part of this discussion) |
| 15:26 | <mikekelly> | my proposal would be so badly written we'd waste all our time arguing about how bad it was |
| 15:26 | <mikekelly> | I'm more interested in why, from this end's perspective - that would be a bad idea |
| 15:27 | <mikekelly> | i.e. what are the obstacles to getting a standardized API agreed upon and implemented |
| 15:27 | <Philip`> | The obstacles are that somebody needs to propose the API and implementors need to be interested in it |
| 15:27 | <mikekelly> | how formal does that proposal need to be? |
| 15:27 | <Philip`> | like in http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F |
| 15:28 | <mikekelly> | isn't this outside of HTML? |
| 15:29 | <Philip`> | There aren't any formal requirements, it should just try to clearly describe the problem that you're trying to solve, and your suggested way of solving it, in a way that other people can understand and agree with |
| 15:29 | <Philip`> | The same process should probably apply to any proposals for web browser features |
| 15:29 | <mikekelly> | ok then consider the last 10 minutes of this discussion my proposal |
| 15:29 | <mikekelly> | -_- |
| 15:30 | <Philip`> | That won't work because nobody will read it |
| 15:31 | <mikekelly> | ok so who are the people worth tlaking to direct about this |
| 15:31 | <mikekelly> | they must be in here.. |
| 15:32 | <Philip`> | Email works better for this kind of thing |
| 15:32 | <mikekelly> | which list? |
| 15:33 | <mikekelly> | I'd still like to chat on here anyway it's a lot easier than back/forthing emails |
| 15:34 | Philip` | remembers some previous HTTP authentication discussion on the WHATWG list but doesn't remember what happened to it or if there's a better place now |
| 15:34 | <mikekelly> | Hixie: can you think of any reason to object to such a javascript API ? |
| 15:34 | <mikekelly> | yeah the problem with that one was |
| 15:34 | <mikekelly> | they were tyring to standardise some HTML way of doing that |
| 15:34 | <mikekelly> | which I think is pointless |
| 15:34 | <mikekelly> | just need a standard JS API |
| 15:34 | <mikekelly> | and let apps handle it as code on demand |
| 15:35 | <mikekelly> | you need.. Auth.set, Auth.flush, and Auth.isSet |
| 15:35 | <mikekelly> | that's about it |
| 15:36 | <mikekelly> | in some ways it would be good to have this method of controlling all headers |
| 15:36 | <mikekelly> | :) |
| 15:37 | <mikekelly> | but Auth's a specific case where you probably don't want to provide accessor |
| 15:37 | <mikekelly> | for obvious reasons :) |
| 15:38 | <mikekelly> | Philip`: if I posted this to WHATWG and went on to say I thought this was separate from HTML |
| 15:39 | <mikekelly> | I'm going to get told it's not up for discussion |
| 15:42 | <mikekelly> | so.. can I post that kind of thing to WHATWG list? Is there somewhere else? Is it like this on purpose so you guys don't have to bother yourselves with the real world?! ;) |
| 15:43 | <Philip`> | I don't think the WHATWG is being unreasonable by not being the place to solve all the world's problems at once |
| 15:44 | <mikekelly> | thank god we're getting video tags sorted |
| 15:44 | <Dashiva> | What's wrong with posting it to a w3c list? |
| 15:44 | <mikekelly> | what's wrong with just discussing it on here first so you can explain why I'm so clearly wrong and we can all avoid wasting any more time? |
| 15:45 | <Philip`> | Because people here either don't know much about the topic and/or don't care about it and/or don't want to talk you and/or are away |
| 15:45 | <mikekelly> | clearly they do care about it there was enough ping/pong last time it came up |
| 15:46 | <mikekelly> | or do we need some time to think up some super-clever reasons why this "just isn't going to happen" |
| 15:47 | <Dashiva> | Whatwg exists to pick up the balls w3c drops. It's best to check if w3c is actually going to drop it first. :) |
| 15:47 | <mikekelly> | well.. the line I was given before was |
| 15:47 | <mikekelly> | it matters not a feck what the standards say if we don't give a toss about it |
| 15:48 | <mikekelly> | so.. to avoid *wasting my time* I'll just skip the beuracracy and ask you direct |
| 15:48 | <mikekelly> | 1. Why won't it work and/or 2. Why don't you care |
| 15:52 | <mikekelly> | "it doesn't matter" doesn't make much sense given the previous discussions around the same issue |
| 15:52 | <mikekelly> | so.. why won't it work ? |
| 15:58 | webben | suspects more relevant questions might be 1. Why should people care (what problem are you trying to solve)? 2. How might it work (what different solutions are there)? |
| 16:00 | <Dashiva> | And how it interacts with the other open suggestions relating to auth headers |
| 16:05 | <mikekelly> | webben: 1. A sensible way to use the Authorization header beyond HTTP Basic and the hideous login prompt |
| 16:05 | <mikekelly> | 2. A standard JS API for setting/flushing the header |
| 16:06 | <mikekelly> | as long as there's an API.. it can be used |
| 16:06 | <mikekelly> | just like XHR |
| 16:10 | <webben> | mikekelly: That doesn't explain the problem you're trying to solve in end-user terms. |
| 16:13 | <mikekelly> | what? |
| 16:13 | <mikekelly> | if you literally mean end users using applications |
| 16:14 | <mikekelly> | then the difference between logging in through a form which POSTs to some endpoints and initiates a cookie'd session vs. a javascript rigged form that sets the Authorization header.. |
| 16:14 | <mikekelly> | is nothing. |
| 16:14 | <mikekelly> | but the difference in terms of the underlying system is vast |
| 16:15 | <mikekelly> | since one is session based (using cookies) and the other is stateless (how HTTP is intended) |
| 16:16 | <mikekelly> | I shouldn't have to give you a lesson in why or how those are hugely different |
| 16:17 | <mikekelly> | but - yes - the 'user experience' is 'already solved' |
| 16:18 | <mikekelly> | webben: so.. where do we go from here? |
| 16:18 | <webben> | mikekelly: I think that makes for a harder sell, since there are a lot of features that need specifying/implementing that make a big difference to the user experience. |
| 16:18 | <mikekelly> | are you from the browser club? |
| 16:19 | <webben> | No. I'm a web developer. |
| 16:19 | <mikekelly> | hmm |
| 16:19 | <mikekelly> | really? fair enough. |
| 16:20 | <mikekelly> | the sell is supporting web architecture and recognizing an obvious problem and a simple solution.. |
| 16:20 | <mikekelly> | :) |
| 16:21 | <mikekelly> | one could easily argue that video tags, SVG, etc. are all user experiences which are achievable via flash objects |
| 16:22 | <webben> | I think they offer a better user experience. |
| 16:22 | <mikekelly> | and why is that? |
| 16:22 | <daedb> | Because Flash is crap. |
| 16:23 | <webben> | Flash is crashy, has poor platform support, has poor accessibility support, has poor restylability support, and introduces additional security risks. |
| 16:23 | <mikekelly> | poor platform support? |
| 16:23 | <webben> | Yes. |
| 16:23 | <mikekelly> | I'm sure HTML5 will have humougous support |
| 16:23 | <mikekelly> | and no browser compat problems at all |
| 16:24 | <mikekelly> | I'm not being serious btw I'm just giving you an example of how pointless that 'user experience' line of argument is |
| 16:24 | <mikekelly> | it's not a realistic way of looking at 'users' |
| 16:24 | <webben> | HTML5 (as a description of the intersection of implementations) already has wider platform support. |
| 16:24 | <Dashiva> | Flash is closed, so it can by definition not be part of the open web platform... |
| 16:24 | <mikekelly> | open web is not user experience |
| 16:24 | <mikekelly> | nobody cares. |
| 16:24 | <mikekelly> | don't kid yourself |
| 16:24 | <daedb> | Flash is Adobe's way of trying to skullfuck the web. |
| 16:25 | <webben> | Flash's development is controlled by Adobe; it's a bit vague to say it's "closed". |
| 16:25 | <mikekelly> | so are websockets |
| 16:25 | <mikekelly> | but there you go |
| 16:25 | <webben> | (the specs are open to implementors now) |
| 16:25 | <mikekelly> | "hey I suck at HTTP - I know! WebSockets!" |
| 16:25 | <mikekelly> | you really should not have used 'web' in websockets |
| 16:26 | <mikekelly> | that really is a bit of a stretch. |
| 16:26 | <webben> | I don't think your example of pointlessness is a valid one. |
| 16:26 | <mikekelly> | sure it is |
| 16:26 | <mikekelly> | flash works fine in all major browsers |
| 16:26 | <mikekelly> | nobody has a problem with it |
| 16:26 | <mikekelly> | apart from people on Mac but then.. |
| 16:26 | <daedb> | Although it's too bad that I don't know Flash... then I could apply for a job that sends me to Florida for 3 months :p |
| 16:27 | <webben> | mikekelly: The first claim is true, but does not contradict my claims. The second claim is untrue. Lots of people have lots of problems with Flash. |
| 16:27 | <mikekelly> | meh - it works |
| 16:27 | <webben> | (Given the web's usage, a small proportion of users is still a lot of people.) |
| 16:28 | <mikekelly> | ok well I wasn't being completely serious just proving a point re: 'user experience' |
| 16:28 | <webben> | You didn't persuade me, I'm afraid. |
| 16:29 | <mikekelly> | mmhmm |
| 16:29 | <webben> | mikekelly: Have you considered trying to implement your idea in one of the various open source libraries? |
| 16:30 | <mikekelly> | I've considered how easy the implementation would/should be |
| 16:31 | <webben> | That's not really the same thing. |
| 16:31 | <webben> | http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element |
| 16:31 | <mikekelly> | Fascinating. |
| 16:32 | <mikekelly> | ok so the point I've got to here is |
| 16:33 | <mikekelly> | "that would probably work but unfortunately the 'user experience' would not change and therefore it has no value" |
| 16:33 | <webben> | I don't understand how you conclude that from our discussion. |
| 16:33 | <mikekelly> | I'm not coding a PoC for something that simple |
| 16:33 | <mikekelly> | complete waste of time |
| 16:34 | <webben> | I didn't offer any ideas on whether it would work; I said that if it wouldn't have an end-user impact it would be a harder sell. |
| 16:34 | <mikekelly> | the end user impact is that they will be using stateless HTTP Authorization |
| 16:34 | <webben> | that's a technical detail, not an end-user impact |
| 16:34 | <mikekelly> | so is the openness of flash. |
| 16:35 | <webben> | I didn't raise the "openness of flash". |
| 16:35 | <mikekelly> | and object vs. video tags |
| 16:35 | <mikekelly> | and anything else in HTML |
| 16:35 | <webben> | Lots of things in HTML have end-user impact. |
| 16:35 | <mikekelly> | lots of things being added to html5? |
| 16:36 | <Dashiva> | Video, whether you agree with it or not, was a fairly easy sell |
| 16:36 | <webben> | I've already explained some of the reasons I think 'video' has end-user impact. |
| 16:37 | <mikekelly> | ok well you're failing to accept tthat developers and service/content providers are also users of html.. |
| 16:37 | <mikekelly> | they care about stateless Auth |
| 16:37 | <mikekelly> | well.. the smart ones who know what they're talking about do |
| 16:37 | <webben> | mikekelly: No I'm differentiating between typical users and developers; and saying that features that affect the former are an easier sell. |
| 16:38 | <mikekelly> | why? so the browser vendors get more chicks? |
| 16:38 | <mikekelly> | can you please explain why that is the case..?! |
| 16:38 | <webben> | Because features that affect the primary user are more likely to increase software's share of the market. |
| 16:39 | <mikekelly> | 'primary user'? |
| 16:39 | <Dashiva> | "Users are more important than authors" |
| 16:39 | <mikekelly> | yes I'm asking you WHY you make that distinction |
| 16:39 | <mikekelly> | and how you justify that |
| 16:39 | <webben> | It seems self-evident to me. |
| 16:39 | <mikekelly> | oh ok then |
| 16:39 | <othermaciej> | hi all |
| 16:39 | <mikekelly> | I thought the web arch guys were supposed to be religious.. :) |
| 16:40 | <Dashiva> | The web exists for the users |
| 16:40 | <mikekelly> | bullshit |
| 16:40 | <webben> | Am I supposed to be a "web arch guy"? |
| 16:40 | <mikekelly> | it's client/server |
| 16:40 | <mikekelly> | webben: clearly not. |
| 16:40 | <Dashiva> | webben: No, mikekelly is |
| 16:40 | <webben> | Oh I see. |
| 16:41 | <mikekelly> | 16:46 < Dashiva> The web exists for the users < please explain this sentiment |
| 16:41 | <mikekelly> | the web is client/server |
| 16:41 | <webben> | mikekelly: Do you disagree that most users of popular browsers are not coders who would use your feature directly? |
| 16:42 | <mikekelly> | they aren't coders but they would use my feature directly |
| 16:42 | <mikekelly> | not conciously but they would use it.. |
| 16:42 | <webben> | mikekelly: And that developer choice of what APIs to use are primarily determined by popular browser choices? |
| 16:42 | <mikekelly> | well that's given.. |
| 16:42 | <mikekelly> | the sky is blue btw |
| 16:43 | <mikekelly> | where are you going with this..? |
| 16:44 | <mikekelly> | when people get HTML.. and run javascript + ajax.. they are using XHR |
| 16:44 | <webben> | So do you disagree that popular browsers stand to gain more marketshare by improving the user experience of those typical users than by putting the same energy into providing APIs not implemented by other browsers, that developers will adopt on the basis of market share? |
| 16:45 | <mikekelly> | obsolutely not because it's an utterly imperfect market |
| 16:45 | <mikekelly> | which you know very well |
| 16:45 | <mikekelly> | or at least you should |
| 16:45 | <webben> | I suspect most markets are imperfect one way or another. |
| 16:45 | <mikekelly> | so you all just sit on your arses trying to dream up 'sexy' fluff |
| 16:46 | <mikekelly> | while we have to do real work and deal with the bullshit you wont address |
| 16:46 | <webben> | mikekelly: Do you contend that neither action has an effect on marketshare, then? |
| 16:46 | <Dashiva> | It doesn't seem like your proposal adds much except being sexy for fans of HTTP... |
| 16:46 | <mikekelly> | Dashiva: yeah.. fans of HTTP happen to be a MASSIVE economic force |
| 16:47 | <webben> | mikekelly: What action do you think popular browsers can take to increase their marketshare? |
| 16:47 | <mikekelly> | a huge consumer of resources.. |
| 16:47 | <Dashiva> | No, they happen to be a very small group of people |
| 16:47 | <mikekelly> | erm.. |
| 16:47 | <mikekelly> | no, |
| 16:47 | <Dashiva> | _Users_ of HTTP are a different story |
| 16:47 | <mikekelly> | what?! |
| 16:47 | <mikekelly> | are you fking insane? |
| 16:48 | <Dashiva> | What percentage of people do you think even know what HTTP is? |
| 16:48 | <mikekelly> | 'fans' of HTTP happen to be anyone *DOING BUSINESS ON THE WEB* |
| 16:48 | <Dashiva> | Hardly |
| 16:48 | <mikekelly> | erm |
| 16:48 | <mikekelly> | ah man |
| 16:48 | <webben> | mikekelly: I like cats. That doesn't make me a fan of the precise evolution of cats' digestive systems. |
| 16:48 | <Dashiva> | HTTP is a tool. If it does the job, that's all they care about. |
| 16:48 | <mikekelly> | no |
| 16:49 | <mikekelly> | HTTP and tooling around that has direct effect on their capital expense |
| 16:49 | <webben> | mikekelly: The user experience does not make users a fan of the mechanics of how that experience is delivered. |
| 16:49 | <webben> | (not automatically, anyhow) |
| 16:49 | <mikekelly> | scalable, evolveable systems SAVE on capital expense |
| 16:49 | <mikekelly> | so this isn't just 'fanbois' |
| 16:49 | <mikekelly> | this is business people |
| 16:49 | <Dashiva> | It's a _tool_ |
| 16:49 | <mikekelly> | fucking hell |
| 16:49 | <mikekelly> | it's a PROTOCOL |
| 16:50 | <Dashiva> | SPDY is a good hint. If the tool doesn't fit well, you look for a better one. |
| 16:50 | <webben> | Punctuating your discussion with expletives and uppercase does not make your arguments more effective. |
| 16:51 | <mikekelly> | ok so - stateless auth means that the system is more efficient |
| 16:51 | <mikekelly> | so it's faster |
| 16:51 | <mikekelly> | so users experience a faster website |
| 16:51 | <mikekelly> | there you go. |
| 16:52 | <Dashiva> | You replace one header with another |
| 16:52 | <mikekelly> | is that a joke? |
| 16:52 | <Dashiva> | Sessions are already possible both with and without http auth |
| 16:52 | <webben> | right so finally we're back to talking about the end-user experience. |
| 16:53 | <mikekelly> | sessions shouldn't have to exist full stop |
| 16:53 | <webben> | mikekelly: So the goal is to increase the speed of the user experience? |
| 16:53 | <mikekelly> | using HTTP Auth eliminates the need for sessions |
| 16:53 | <mikekelly> | that is my point |
| 16:53 | <mikekelly> | avoiding sessions results in far more scalable systems |
| 16:53 | <mikekelly> | that are more efficient |
| 16:54 | <mikekelly> | so they run faster and consume less resources |
| 16:54 | <mikekelly> | which is good for everyone. |
| 16:54 | <webben> | mikekelly: Which would increase the speed of user experience more? This or SPDY? |
| 16:54 | <mikekelly> | that has nothing to do with what I'm talking about.. SPDY is mostly optmization on top of HTTP |
| 16:55 | <webben> | mikekelly: Heck, this or developers compressing their JS/using CDNs. |
| 16:55 | <webben> | mikekelly: It has everything to do with the end goal of increasing the speed of the user experience. |
| 16:55 | <mikekelly> | CDNs and Js compression have nothing to do with one another |
| 16:55 | <webben> | mikekelly: They share the goal of increasing the speed of the user experience. |
| 16:55 | <mikekelly> | terrific thanks for that |
| 16:55 | <webben> | (Well, that's one benefit.) |
| 16:56 | <mikekelly> | webben: statless HTTP requests have the goal of increasing the efficiency of systems and improving user experience |
| 16:57 | <webben> | mikekelly: So when asking: is this worth doing, you need to consider whether there are other solutions that do more, not just whether your solution would have any effect at all. |
| 16:57 | <mikekelly> | right.. :/ |
| 16:58 | <webben> | mikekelly: In particular, it's worth noting that JS compression for example works with all popular user agents so it's more attractive to typical developers than a feature where you'd need to code an alternative for popular browsers that don't support it. |
| 16:59 | <mikekelly> | thanks for the heads up |
| 17:00 | <webben> | Sarcasm doesn't make your arguments more effective either. |
| 17:00 | <mikekelly> | That is why this conversation revolves around a standard API for setting/flushing the Auth header.. |
| 17:01 | <mikekelly> | note: standardized |
| 17:01 | <mikekelly> | i.e. 'popular browsers support it' |
| 17:01 | <mikekelly> | like XHR.. |
| 17:01 | <mikekelly> | so.. anyway.. |
| 17:01 | <mikekelly> | Dashiva: using HTTP Auth eliminates the need for sessions - avoiding sessions results in far more scalable systems that are more efficient - so they run faster and consume less resources |
| 17:01 | <webben> | mikekelly: In some distant future. In the meantime, browsers can implement features that deliver (arguably) more significant user benefits right now. |
| 17:02 | <webben> | Implementing features that benefit users right now is likely to be more attractive. |
| 17:02 | <mikekelly> | and that statement discludes my suggestion because of some bullshit arbitrary definition of 'user' |
| 17:02 | <mikekelly> | and 'benefit' |
| 17:02 | <webben> | It does not seem arbitrary to me. |
| 17:02 | <mikekelly> | well it is - which is why you can't quantify them |
| 17:04 | <webben> | I don't understand how my ability to quantify them would say anything about the arbitrariness of the definition. |
| 17:05 | <Dashiva> | (A system large enough to need good scalability likely has requirements on user experience that dictate hardware investment. More efficient systems would just mean less hardware used, not better user experience.) |
| 17:06 | <mikekelly> | Dashiva: yes - I guess if they get more users they should just go down the money tree for a few hours |
| 17:06 | <mikekelly> | lets be a bit more realistic an assume there isn't a bottomless pit of money.. |
| 17:06 | <othermaciej> | I think most sites do not use HTTP Auth because they want to control the login UI themselves |
| 17:07 | <mikekelly> | NO |
| 17:07 | <mikekelly> | really? |
| 17:07 | <othermaciej> | I don't think it has anything to do with scalability issues |
| 17:07 | <mikekelly> | well clearly not - moving away from statelessness (HTTP Auth) is not in the interest of scalability |
| 17:07 | <mikekelly> | that is my point |
| 17:07 | <othermaciej> | mikekelly: whoah there turbo |
| 17:08 | <othermaciej> | let's try to hold back our all-caps sarcasm |
| 17:08 | <othermaciej> | HTTP Auth isn't stateless |
| 17:09 | <othermaciej> | well, depending on what you mean by stateless |
| 17:09 | <mikekelly> | you weren't here but the start of this convo was my proposal for a JS API that can set/flush the Auth header.. which would allow html+js UI to log in and out |
| 17:09 | <mikekelly> | othermaciej: no 'shared state'; i.e. no session |
| 17:09 | <othermaciej> | digest auth has both permanent state on the client (saved username / pw) and temporary state (the nonce) |
| 17:10 | <mikekelly> | and you can leverage that from html+js ? |
| 17:11 | <othermaciej> | A JS API to set a username/password pair to use for a specific protection space on a particular server might be useful |
| 17:11 | <othermaciej> | I don't think it would result in things being any less stateful |
| 17:11 | <othermaciej> | your responses still have to vary based on the Authorization header |
| 17:11 | <othermaciej> | (instead of based on Cookie) |
| 17:12 | <othermaciej> | in fact with digest auth Authorization is different every time, so it's harder to build a reverse proxy that caches effectively |
| 17:12 | <mikekelly> | no, that's what layering is for |
| 17:12 | <othermaciej> | and basic auth sends the password in essentially plaintext every time, which is broken |
| 17:12 | <mikekelly> | whereas sessions are perfectly secure of course |
| 17:14 | <mikekelly> | Digest isn't different every time, regardless using tokens (whether they contain variable nonces etc) in the Auth header doesn't require shared state/token |
| 17:14 | <Dashiva> | There's already one or two proposals for combining form login with HTTP auth |
| 17:14 | <mikekelly> | Which is why I would say a simple API to set/flush |
| 17:15 | <webben> | Arguments of the form: "We can ignore problem X with Solution A, because Solution B is not totally immune to similar problems." aren't very strong. |
| 17:15 | <mikekelly> | othermaciej: a set/flush would provide a generic mechanism for any HTTP Auth mechanism |
| 17:16 | <mikekelly> | Digest,OAuth, WSSE, etc. |
| 17:16 | <mikekelly> | js picks up 401's - parses WWW-Authenticate header |
| 17:16 | <mikekelly> | does it's magic |
| 17:16 | <mikekelly> | sets the Authorization header |
| 17:17 | <othermaciej> | you really don't want to set the actual Auth header |
| 17:17 | <mikekelly> | why is that? |
| 17:17 | <othermaciej> | because the client is not in a position to compute the digest for every resource |
| 17:17 | <mikekelly> | it wouldn't.. it would set it |
| 17:17 | <mikekelly> | and the API would persist it |
| 17:17 | <mikekelly> | the same way it does if you log in with Basic |
| 17:17 | <othermaciej> | when you load a page and its subresources over http digest auth, each resource needs a different Authorize header |
| 17:18 | <mikekelly> | no it doesn't.. |
| 17:18 | <othermaciej> | "The Digest scheme challenges |
| 17:18 | <othermaciej> | using a nonce value. A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given |
| 17:18 | <othermaciej> | nonce value, the HTTP method, and the requested URI." |
| 17:18 | <othermaciej> | from the RFC |
| 17:19 | <othermaciej> | it's a challenge-response protocol |
| 17:19 | <othermaciej> | you can't set a valid response before seeing the chalenge |
| 17:19 | <othermaciej> | many other strong auth methods (NTLM, Kerberos) also work on a challenge/response basis |
| 17:20 | <mikekelly> | right - but the client credentials don't change.. |
| 17:20 | <othermaciej> | the username and password don't change |
| 17:21 | <othermaciej> | so you could let JS tell those to the browser |
| 17:21 | <mikekelly> | with the auth echeme |
| 17:21 | <othermaciej> | but the *header* that you send |
| 17:21 | <othermaciej> | that does change |
| 17:21 | <mikekelly> | a decent point |
| 17:21 | <mikekelly> | thank you |
| 17:21 | <mikekelly> | :) |
| 17:22 | <mikekelly> | so an api per supported Auth scheme? |
| 17:23 | <othermaciej> | a single server can have multiple named protection spaces |
| 17:23 | <mikekelly> | where credentials are presisted and the header calculated |
| 17:23 | <mikekelly> | realms? |
| 17:23 | <othermaciej> | right, realms |
| 17:23 | <mikekelly> | yeah - that's ok right? |
| 17:23 | <othermaciej> | you'd need a username/password per {protocol,host,port,realm} tuple |
| 17:24 | <mikekelly> | realm is specified in the request |
| 17:24 | webben | vaguely wonders whether HTTP Auth could be directly supported in HTML with something likely digestUsername="#idref" and a digestPassword="#idref" on any element taking an "action" attribute. |
| 17:24 | <webben> | *like |
| 17:24 | <mikekelly> | it's much easier for everyone if it's just a JS API |
| 17:25 | webben | disagrees. |
| 17:25 | <Dashiva> | It's much easier if we provide a way to map a regular non-JS form to an auth response |
| 17:25 | <othermaciej> | not sure |
| 17:25 | <othermaciej> | doing it declaratively is handy |
| 17:25 | <othermaciej> | but the JS API could also be useful |
| 17:25 | <mikekelly> | it is - but it's way less risk as an API |
| 17:26 | <webben> | Sure, I didn't mean having an HTML feature would mean a JS feature would be bad. |
| 17:26 | <mikekelly> | at least then you can see how it behaves 'in the wild' and make the judgement |
| 17:26 | <othermaciej> | that being said, I don't see how http auth is any less stateful, and as I said before, it seems harder to cache via areverse proxy |
| 17:26 | <webben> | Not sure how it's less risk as an API. |
| 17:26 | <mikekelly> | Vary: Authorization |
| 17:26 | <othermaciej> | Vary: Authorization is no better than Vary: Cookie |
| 17:27 | <mikekelly> | it's not harder |
| 17:27 | <othermaciej> | in fact it's worse, because the Authorization header is different every single time with strong auth schemes |
| 17:27 | <mikekelly> | you generally can't cache a private resource anyway |
| 17:27 | <othermaciej> | whereas session cookies persist |
| 17:27 | <mikekelly> | depending on how you build your systems |
| 17:28 | <othermaciej> | on a system like facebook nearly every resource is private |
| 17:28 | <othermaciej> | also, both Authorization and Cookie are added promiscuously - the only way to exclude them from non-private resources is to put those on a separate subdomain |
| 17:29 | <mikekelly> | why is that a problem? |
| 17:30 | <othermaciej> | you can't put your main page on a separate subdomain |
| 17:30 | <othermaciej> | anyway |
| 17:30 | <mikekelly> | why would you want to? |
| 17:30 | <mikekelly> | the resposne determines cachability |
| 17:30 | <othermaciej> | I think a version of your proposal is reasonable, but I don't think your justification for it (less stateful / more scalable) seems sound to me |
| 17:30 | <mikekelly> | the fact that request contained cookie or auth header is irrelevant |
| 17:31 | <mikekelly> | othermaciej: it's simple; there's no shared state by session |
| 17:31 | <mikekelly> | which means the server side doesn't need to maintain any session |
| 17:31 | <mikekelly> | which makes horizontal scalability lot more simple |
| 17:32 | <mikekelly> | the only thing you're worring about there is the nonce |
| 17:32 | <mikekelly> | which is a lot less of a challenge than a pool of sessions, for obvious reasons |
| 17:33 | <mikekelly> | no? |
| 17:36 | <webben> | Although for the next five years or so, you'd still need a pool of sessions for users of browsers that don't support the API, if you wanted to give them the same login UI? |
| 17:36 | <mikekelly> | how many new features fall into that category? |
| 17:37 | <othermaciej> | I don't understand why storing the nonce is less of a burden than storing a session cookie |
| 17:37 | <othermaciej> | I suppose you could time it out more aggressively |
| 17:38 | <webben> | mikekelly: Many features require double provision; I think it's rare for that double-provision to prevent one realizing the benefits of single provision. |
| 17:38 | <webben> | that is to say, if you have to maintain nonces and sessions, has scalability gotten any simpler? |
| 17:39 | <webben> | Contrast SPDY. In theory, that runs from the same web servers on the same machines. If a client supports it, their user experience will be faster; if not, it won't. |
| 17:39 | <mikekelly> | ... |
| 17:39 | <mikekelly> | :/ |
| 17:39 | <webben> | The need to cater to clients that don't support does not negate its advantages. |
| 17:39 | <webben> | *don't support it |
| 17:39 | <webben> | Do you see what I mean? |
| 17:41 | <mikekelly> | if it's an API it would be possible to write work-arounds for legacy clients |
| 17:41 | <mikekelly> | of course |
| 17:41 | <webben> | mikekelly: I'm talking about the server. |
| 17:41 | <mikekelly> | sure - the web is an evolutionary thing |
| 17:42 | <mikekelly> | it doesn't improve by magic.. |
| 17:42 | <mikekelly> | you're asking me what my objective is |
| 17:43 | <webben> | That doesn't undermine the distinction - for individuals developers - between adopting a feature that can improve X now, versus one that could only improve X in five years time and in the meantime makes X more complicated. |
| 17:44 | <mikekelly> | ok well we have big players in the web |
| 17:44 | <mikekelly> | I'm sure if they thought they could cut costs they'd be interested |
| 17:44 | <webben> | SPDY can improve performance now, even if it makes delivering performance more complicated. Seems to me you're saying this API would improve scalability in five years or so, while making scalability more complicated in the meantime. |
| 17:44 | <webben> | Which could in fact increase costs, as far as I can see. |
| 17:45 | <mikekelly> | it's really not that complicated if you're systems are built properly :) |
| 17:45 | <webben> | mikekelly: I didn't make any judgement about *how* much more complicated it is. |
| 17:45 | <webben> | Simply that is is more complicated. |
| 17:45 | <mikekelly> | ok well then you can't just make that judgement it has to be in some context |
| 17:45 | <webben> | benefits vs costs |
| 17:46 | <mikekelly> | ok it could be 4 days of work complicated |
| 17:46 | <webben> | immediate benefit: 0; immediate cost: >0 (due to it being more complicated) |
| 17:46 | <mikekelly> | and 20 million saved in beenefit |
| 17:46 | <webben> | how is this 20 million saved if you still need to maintain the session pool? |
| 17:47 | <mikekelly> | 20 million as 15% of some massive scale |
| 17:47 | <webben> | How though? |
| 17:48 | <mikekelly> | with a really well designed, distributed system |
| 17:48 | <webben> | That doesn't really answer the question. |
| 17:48 | <mikekelly> | you want a web arch lesson? |
| 17:49 | <webben> | I'd like a concise explanation of how you'd increase scalability while maintaining a session pool. |
| 17:49 | <mikekelly> | Roy Fielding wrote his dissertation on a style of building systems that seems to work quite well. :) |
| 17:50 | <mikekelly> | I know I'm not realy allowed to say that |
| 17:50 | <webben> | How would you apply the ideas in that dissertation to solve this problem? |
| 17:51 | <mikekelly> | by leveraging the layered constraint as it applies to HTTP. |
| 17:51 | <webben> | Which means what? |
| 17:51 | <mikekelly> | have you read the paper? |
| 17:52 | <webben> | A while ago, yeah. |
| 17:52 | <mikekelly> | statelessness is a primary constraint of the style he outlines there |
| 17:53 | <webben> | Okay ... but your solution still has to involve "state" because it has to include a session pool. |
| 17:53 | <mikekelly> | mmmhmm.. |
| 17:54 | <mikekelly> | if the components of whatever makes up your system are decoupled then it's a lot easier to "partition" in the way you seem to think is so impossible |
| 17:55 | <webben> | mikekelly: Are you saying you'd basically have one lot of servers handle requests using your API and another lot handle requests using sessions? |
| 17:55 | <mikekelly> | regardless - features like this can have application and value, the fact that we may have to wait until it is appropriate for mass distribution is irrelevant, and sitting around worrying about that isn't going to make it happen |
| 17:56 | <webben> | It may be irrelevant to you. It's not irrelevant to developers of clients or servers considering implementing the feature. |
| 17:57 | <webben> | Especially, when they could implement something else to realize cost-savings, like SPDY. |
| 17:58 | <mikekelly> | why do you keep referring to SPDY as an alternative to this? |
| 17:59 | <webben> | mikekelly: Because it also offers a faster user experience with (potentially) lower costs. |
| 18:00 | <mikekelly> | and that somehow eliminates the benefit here how? |
| 18:00 | <webben> | It doesn't elimate the putative benefit; it means the benefit/cost ratio of one action is higher than the other action. |
| 18:01 | <webben> | So rational actors are more likely to take the former action - because time/resource/money is limited. |
| 18:01 | <webben> | *eliminate |
| 18:02 | <mikekelly> | .. right .. |
| 18:02 | <mikekelly> | :) |
| 18:03 | <webben> | So I'd suggest developing a client/server pair that implements your ideas along the lines of SPDY would be a good way to gain traction for them. |
| 18:05 | <mikekelly> | a client/server pair that implements some form of HTTP Authorization? |
| 18:05 | <mikekelly> | I don't think I need to bother. |
| 18:06 | <mikekelly> | http://docs.amazonwebservices.com/AmazonS3/2006-03-01/index.html?RESTAuthentication.html |
| 18:07 | <webben> | yeah, I meant a client implementing your JS API and a server system that supports session pools and nonces simultaneously. |
| 18:08 | <webben> | not just any old implementation of HTTP Authorization. |
| 18:08 | <mikekelly> | to prove what? that the programming languages work ok? |
| 18:09 | <webben> | mikekelly: Well, if nothing else, you'd then be able to submit patches to the systems you'd modified in order to have actual implementations. |
| 18:09 | <webben> | mikekelly: Though I suspect you might also refine the ideas through actual implementation. |
| 18:09 | <mikekelly> | that sounds like a terrific waste of time |
| 18:10 | <webben> | mikekelly: Is that because you'd have to learn a lot of new code to contribute the patch to an existing browser? |
| 18:12 | webben | is confused as to why it's a terrific waste of time for you, but a great use of others' time. |
| 18:13 | <mikekelly> | .. this conversation is turning into a terrific waste of time |
| 18:14 | <mikekelly> | it's a waste of time because 1. I'm not a browser dev and 2. what's the point if nobody agrees anyway |
| 18:15 | <othermaciej> | I'm a browser dev and we'd probably take a WebKit patch to implement something like this, if it also got discussion in the relevant standards |
| 18:21 | <mikekelly> | othermaciej: that was really my initial query - where abouts would you 'take' something like this |
| 18:24 | <mikekelly> | because if it's "just" a JS API like XHR it doesn't really belong in HTML spec |
| 18:24 | <mikekelly> | right? |
| 18:39 | <webben> | mikekelly: http://www.w3.org/2008/webapps/ and WHATWG would seem appropriate forums. |
| 19:12 | <Philip`> | "an already almost one million pixels height spec" |
| 19:13 | <Philip`> | That's the first time I've seen it measured in those units |
| 19:14 | <daedb> | Well we could always increase the line-height, then it'll be even taller! |
| 22:57 | <jgraham> | Argh. Email is not twitter. tinyurl is totally unnecessary |
| 22:57 | <AryehGregor> | Dashiva, just do {| class="prettytable" and define .prettytable at [[MediaWiki:Common.css]], that's what Wikipedia does. We don't add extra styles IIRC, {| just produces <table>. |
| 22:58 | <jgraham> | By which I mean "both irritating and harmful" |
| 22:59 | <webben> | jgraham: Hmm. Some URLs get broken and more than ~75 chars. |
| 22:59 | <webben> | *at more |
| 22:59 | <jgraham> | webben: Personally I find copy and paste to be less bad than playing "guess the destination" |
| 23:00 | <webben> | jgraham: aliases help. |
| 23:01 | <webben> | (you might be able to find a de-tinyifier for your email-consuming software fwiw) |
| 23:59 | <Dashiva> | If nothing else, the recent events are giving a glimpse at what people really think behind the masks... |
