| 01:56 | <billyjackass> | http://tools.ietf.org/html/rfc5598 |
| 01:57 | <billyjackass> | Internet Mail Architecture |
| 01:57 | <billyjackass> | "describes the realities of the current system" |
| 01:57 | <billyjackass> | an RFC that describes realities |
| 04:08 | Hixie | rewrites his preprocessor script so it doesn't have to run through the source file a dozen times but instead generates all the concrete source files in one pass |
| 04:18 | <boblet> | hi all |
| 04:33 | <MikeSmith> | boblet: hey |
| 04:33 | <MikeSmith> | HOT in Tokyo |
| 04:34 | <boblet> | MikeSmith: hi Mike. How’s things? |
| 04:34 | <MikeSmith> | hot |
| 04:34 | <boblet> | haha, was just gonna ask that :D |
| 04:34 | <boblet> | Sorry I haven’t uploaded that photo of you to Flickr yet (hehehe) |
| 04:35 | <boblet> | was good to catch up and meet your team too |
| 04:37 | <boblet> | MikeSmith: does the spec explicitly state that things like incorrect nesting are wrong? I could only find nesting mentioned in an error handling example… |
| 04:40 | <MikeSmith> | boblet: no, not about incorrect nesting specifically |
| 04:40 | <MikeSmith> | I don't know what you'd classify as other things like incorrect nesting |
| 04:41 | <MikeSmith> | boblet: lemme qualify that statement |
| 04:41 | <boblet> | The good coding practices that were taught via XHTML—closing elements, not dropping optional elements that add meaning etc |
| 04:41 | <boblet> | non-tag soup stuff |
| 04:41 | <MikeSmith> | those are best practices, not errors |
| 04:42 | <MikeSmith> | misnested tags are a real error |
| 04:42 | <MikeSmith> | a parsing error |
| 04:42 | <MikeSmith> | not dropping optional elements is a best practice |
| 04:42 | <boblet> | aah ok. but neither are currently mentioned right? |
| 04:43 | <MikeSmith> | those best-practice things, no |
| 04:43 | <MikeSmith> | IMHO, those are not appropriate for the spec |
| 04:43 | <MikeSmith> | but should just be in authoring guides instead |
| 04:43 | <MikeSmith> | in particular, closing elements for which the end tag is not required is an optional authoring choice |
| 04:43 | <MikeSmith> | in the case of the HTML syntax |
| 04:43 | <MikeSmith> | in the XHTML syntax, it is a parse error |
| 04:44 | <MikeSmith> | because end tags are always required in XHTML |
| 04:44 | <MikeSmith> | well, either that or self-closing start tags |
| 04:44 | <boblet> | ok—thanks for the clarification |
| 04:44 | <MikeSmith> | about misnested tags in particular |
| 04:44 | <MikeSmith> | the spec does not explicitly define what misnested tags are |
| 04:45 | <MikeSmith> | or define what misnesting of tags is |
| 04:45 | <boblet> | the old <b><i></b></i> chestnut is in 9.2.8 |
| 04:45 | <boblet> | but only as an example |
| 04:45 | <MikeSmith> | what it does say explicitly is, "an elements contents must be contained within the element's start tag and end tag" |
| 04:45 | <MikeSmith> | or something very similar to that |
| 04:46 | <MikeSmith> | (despite the quotes, I'm paraphrasing from memory) |
| 04:46 | <boblet> | heh, was gonna ask you for a reference there |
| 04:46 | <MikeSmith> | Hixie reckons that statement is clear enough. but IMHO it could be clearer |
| 04:46 | <MikeSmith> | see the Writing HTML documents section |
| 04:48 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#elements-0 |
| 04:48 | <boblet> | got it |
| 04:48 | <MikeSmith> | "The contents of the element must be placed between just after the start tag (which might be implied, in certain cases) and just before the end tag (which again, might be implied in certain cases)." |
| 04:49 | <MikeSmith> | but if you have some specific proposed text that you think would make it more clear, that would be great |
| 04:49 | <Hixie> | i added more about that to the intro recently |
| 04:49 | <MikeSmith> | Hixie: URL? |
| 04:50 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#a-quick-introduction-to-html |
| 04:50 | <Hixie> | "Tags have to be nested correctly" |
| 04:50 | <MikeSmith> | cool |
| 04:50 | <boblet> | aah—that’s what I was after. Thanks Hixie |
| 04:50 | <Hixie> | i don't understand why anyone would ever get to the conclusion that <b>...<i>...</b>...</i> would be correct, though -- so i don't understand why we need to explicitly say it's wrong |
| 04:50 | <Hixie> | it's never been right |
| 04:50 | <Hixie> | why would anyone even consider that it might be right? |
| 04:51 | <MikeSmith> | now we need to define what "nested correctly" means |
| 04:51 | <MikeSmith> | Hixie: I can see somebody who's not familiar with HTML or markup thinking it should be fine |
| 04:52 | <Hixie> | how can it ever be a valid representation of a tree? |
| 04:52 | <MikeSmith> | it's not absolutely intuitively wrong |
| 04:52 | <MikeSmith> | my not-familar-with-HTML person would respond, "um, What's a tree?" |
| 04:52 | <boblet> | Hixie: that’s why you’re a spec writer and cat wrangler, and not teaching people how to code :D people are … creative |
| 04:53 | <Hixie> | people who don't know what a tree are shouldn't be reading the spec (at least not without learning what a tree is) -- the whole spec is designed based on the tree concept |
| 04:54 | <MikeSmith> | true |
| 04:54 | <boblet> | unfortunately I think a lot of authors still feel the spec (or an official version of it) should be written for them |
| 04:55 | <Hixie> | well lachlan is working on a guide |
| 04:55 | <Hixie> | but i can't write the normative spec without referencing trees |
| 04:55 | <Hixie> | not in a comprehensible fashion, anyway |
| 04:55 | <boblet> | MikeSmith: are there any plans on expanding your “HTML5: The Markup Language” into an author’s guide? |
| 04:55 | <MikeSmith> | no |
| 04:56 | <MikeSmith> | no plans for expanding it all beyond the very limited scope it has now |
| 04:56 | <boblet> | it’ll be interesting to see what Lachlan comes up with |
| 04:56 | <MikeSmith> | I prefer contracting rather than expanding |
| 04:56 | <boblet> | hehe |
| 04:56 | <boblet> | delegating works well too |
| 04:57 | <MikeSmith> | expanding is one of the biggest problems we have in spec/standards development |
| 04:57 | <MikeSmith> | "scope creep" |
| 04:58 | <MikeSmith> | start out with a small, focused information need, then add enough people, next thing you're doing is project SpaceX |
| 04:59 | <MikeSmith> | building a rocket ship to the moon |
| 04:59 | <MikeSmith> | it's not just in standards development, actually |
| 05:00 | <MikeSmith> | in my experience in product development, it's pretty much the same with functional specs |
| 05:00 | <MikeSmith> | especially if you involve the customer |
| 05:00 | <boblet> | well, everyone wants more |
| 05:00 | <MikeSmith> | yeah, I guess so |
| 05:00 | <MikeSmith> | you solve that problem by not trying to make everybody happy |
| 05:01 | <MikeSmith> | by realizing that you *can't* make everybody happy |
| 05:01 | <MikeSmith> | and instead try to get done what's actually most important and most necessary |
| 05:01 | MikeSmith | puts his schoolmarm cap on |
| 05:04 | <MikeSmith> | anyway, about misnested tags, for somebody who doesn't think of HTML in terms of trees or tags as delimiters, but instead as, say, flags or something, then it's not obvious |
| 05:04 | <MikeSmith> | yeah, those people are dunces |
| 05:04 | <boblet> | now now |
| 05:05 | <boblet> | MikeSmith: schoolmarms are supposed to be both prim and *proper* |
| 05:05 | <MikeSmith> | replace it with whatever politically-correct words |
| 05:05 | <Hixie> | jesus wept |
| 05:05 | <Hixie> | http://daten.dieweltistgarnichtso.net/src/cc-license-markup/generator2.xhtml |
| 05:05 | <MikeSmith> | heh |
| 05:05 | <Hixie> | only took like 3 hours for someone to make that - three hours after they learnt of the existence of the feature |
| 05:06 | <Hixie> | that's in addition to jgraham and Philip` both implementing parsers for microdata within 24 horus of the feature being invented |
| 05:06 | <Hixie> | there's something about microdata that really makes people code! |
| 05:06 | <Hixie> | wish i knew what it was so i could reproduce it in other specs |
| 05:06 | <MikeSmith> | good old itemprop |
| 05:06 | <boblet> | har! |
| 05:07 | <MikeSmith> | nice but hardly seems to me at least like an indicator that microdata is taking the world by storm |
| 05:07 | <MikeSmith> | one dude plus jgraham plus Philip` |
| 05:08 | <Hixie> | oh it's clearly not yet |
| 05:08 | <MikeSmith> | it's hardly even enough for a human wave |
| 05:08 | <Hixie> | i'm just amazed at how people learn about it and code something within literally hours |
| 05:08 | <Hixie> | i don't think i've ever specced anything else that has had that effect |
| 05:08 | <MikeSmith> | there's a lot people paying attention, that's for sure |
| 05:09 | <MikeSmith> | and people want to try out new stuff |
| 05:10 | <MikeSmith> | Hixie: I guess much or most of the other stuff you're thinking of is stuff that requires native support in browsers |
| 05:10 | <Hixie> | maybe |
| 05:10 | <MikeSmith> | this doesn't, so people can try it more quickly and do stuff with it |
| 05:10 | <MikeSmith> | and people do want to use new stuff from HTML5 |
| 05:11 | <MikeSmith> | even if all they're doing is changig their doctype to <!doctype html5> |
| 05:11 | <MikeSmith> | in some cases |
| 05:11 | <boblet> | speaking of itemprop, was my feedback in http://lists.w3.org/Archives/Public/public-html/2009Jul/0489.html to the right place? |
| 05:11 | <Hixie> | boblet: yeah it's on the pile |
| 05:12 | <boblet> | cool—just wanted to check I wasn’t doing it wrong |
| 05:12 | <MikeSmith> | anyway, I want to complete my thought on misnested tags, for what it's worth (which is basically nothing, but I'll do it anyway) |
| 05:13 | <boblet> | please do |
| 05:13 | <MikeSmith> | don't encourage me |
| 05:13 | <MikeSmith> | dangerous |
| 05:13 | <boblet> | har! |
| 05:14 | <MikeSmith> | I can imagine somebody seeing a <b> start tag a sort of just meaning "bold on" and </b> end tag as "bold off", and they can turn on and off wherever |
| 05:14 | <MikeSmith> | that's all |
| 05:14 | <MikeSmith> | not a brilliant point |
| 05:14 | <MikeSmith> | but point nonetheless |
| 05:14 | <Hixie> | sure, if they don't realise that tags represent elements, but think they represent on-off flags, then that makes sense |
| 05:14 | <Hixie> | clearly many people do |
| 05:15 | <Hixie> | but if you get to the point in the HTML5 spec where you are looking at the syntax, then you'd better have realigned your worldview by then, because otherwise you really haven't been paying attention :-) |
| 05:15 | <Hixie> | anyway i try to introduce the idea of elements vs on-off in the intro |
| 05:15 | <Hixie> | i can make it even more explicit if you want |
| 05:15 | <Hixie> | e.g. i could include an actual DOM tree |
| 05:15 | <Hixie> | send mail if you think that would help |
| 05:16 | <MikeSmith> | boblet: or post some suggested text to this bug: |
| 05:16 | <MikeSmith> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=6953 |
| 05:17 | <Hixie> | bbl |
| 05:18 | <boblet> | ok, if I can find a better way of wording it… |
| 05:18 | <MikeSmith> | boblet: as for my "dunce" comment I'm reminded of this quote from Doug Crockford |
| 05:18 | <MikeSmith> | "I've discovered that most of the world's body of JavaScript programs is crap." |
| 05:19 | <boblet> | that’s more stating the obvious than dunce :P j/k |
| 05:19 | <MikeSmith> | my point being that in general, we are not dealing with geniuses here |
| 05:20 | <MikeSmith> | hmm, I retract that wording |
| 05:20 | <MikeSmith> | that's an unkind way to put it |
| 05:20 | <boblet> | I do think that authors have the idea that the spec is for them (rather than implementors), and the lack of best practices from an author perspective makes it harder for authors to learn |
| 05:21 | <boblet> | as you say they should buy a book, but I think because the spec is official authors treat it as canon |
| 05:22 | <MikeSmith> | boblet: I personally think there's too much best-practices stuff in the spec already, and that most of what is in there that could be seen as best-practices authoring info should be a different document |
| 05:23 | <boblet> | MikeSmith: I think it’d be a great idea to have a ‘for implementors’ version and a ‘for authors’ version. Not practical now, but later on… |
| 05:23 | <boblet> | I think that’d be the biggest thing you could do to improve the level of coding across the web |
| 05:24 | <MikeSmith> | I think instead we should just do what other standards-development organizations do, and make the specs totally unfriendly to non-implementors |
| 05:24 | <MikeSmith> | even down to the formatting |
| 05:24 | <boblet> | har! ummm… you think they’re not already? ;-) |
| 05:24 | <boblet> | granted, you could try a lot harder |
| 05:24 | <MikeSmith> | forget HTML, we give you plain text. eff off if you don't like it |
| 06:15 | <boblet> | later all |
| 07:07 | <MikeSmith> | hsivonen: proposal: add a separate warnings.sch file for "Conforming but obsolete" attributes, with a note in the README explaiining what it's for |
| 07:07 | <MikeSmith> | good idea? bad idea? |
| 07:07 | <hsivonen> | MikeSmith: good idea. |
| 07:08 | <MikeSmith> | hsivonen: OK, I'll open a bug |
| 07:09 | <MikeSmith> | because I probably won't get to it today and I'll need a reminder |
| 07:09 | <MikeSmith> | but if you get to it before me, lemme know |
| 07:10 | MikeSmith | counts |
| 07:10 | <MikeSmith> | only 5 attributes, so I guess it'll be quick to do |
| 07:11 | MikeSmith | wonders if he can manage to do it before he has to change trains |
| 07:16 | <MikeSmith> | hsivonen: http://bugzilla.validator.nu/show_bug.cgi?id=621 |
| 07:17 | <MikeSmith> | I assigned it to myself |
| 07:20 | <hsivonen> | MikeSmith: thanks |
| 08:13 | <MikeSmith> | Hixie: if/when you have a minute, I'm still trying to wrap my head around what kinds of deployments of Web sockets we might expect to see. Right now, thinking in particular about if/how it needs to work with existing Web servers |
| 08:13 | <MikeSmith> | so, a question - |
| 08:14 | <Hixie> | classic example would be gmail's IM application |
| 08:14 | <MikeSmith> | imagining that somebody implements a module for Apache that adds WebSockets protocol support |
| 08:14 | MikeSmith | nods |
| 08:17 | <MikeSmith> | Hixie: so that IM app would not be implemented with an actual Web server at all anyway |
| 08:17 | <MikeSmith> | tyoshino: hello |
| 08:17 | <Hixie> | MikeSmith: well, right now it is, using XHR and long polling and all that. But yeah, it'd be much better just to have a dedicated IM server. |
| 08:18 | <MikeSmith> | OK |
| 08:18 | <tyoshino> | hello! |
| 08:18 | <MikeSmith> | Hixie: assuming if somebody did add a module to Apache to do the actual handshake stuff, I guess I don't understand what would happen after that |
| 08:19 | <MikeSmith> | I mean, it's not a Web server anymore after that |
| 08:19 | <Hixie> | well there are two ways one could integrate this with apache |
| 08:19 | <Hixie> | for the IM case |
| 08:20 | <Hixie> | either you could have a dedicated apache module that, after the handshake, does exactly what the dedicated IM server we just talked about would do |
| 08:20 | <Hixie> | or, you have an apache module that is someone like the CGI module, in that after the handshake, it hands the socket over to some other script, and that script does the chatting back and forth |
| 08:46 | <MikeSmith> | Hixie: OK, thanks |
| 08:47 | <MikeSmith> | I understand the specific-application dedicated module case fine |
| 08:51 | <hsivonen> | Google FAIL. Searching for AWWW doesn't find me the Architecture but pictures of cute hegdehogs. |
| 08:57 | <MikeSmith> | tyoshino: hot in Tokyo |
| 08:58 | <MikeSmith> | I wish I was in Karuizawa today |
| 08:58 | <tyoshino> | Yeah |
| 08:58 | <tyoshino> | Mee too :) Hot is okay but high humidity is really really bad. |
| 08:59 | <MikeSmith> | yeah |
| 09:04 | <MikeSmith> | tyoshino: maybe if you guys have a developer who's an Apache hacker, he/she could implement a Websockets module for Apache |
| 09:04 | <MikeSmith> | mod_websocket |
| 09:06 | <MikeSmith> | https://issues.apache.org/bugzilla/show_bug.cgi?id=47485 |
| 09:08 | <tyoshino> | I see. |
| 09:10 | <tyoshino> | I dunno if there's such people. Our working plan for server is still in flux. |
| 09:11 | <MikeSmith> | tyoshino: I guess you will need some server-side thing to test against anyway. though it doesn't need to be a full Web server of course |
| 09:11 | <tyoshino> | Yes. |
| 09:13 | <tyoshino> | As Fumitoshi wrote in the design documents, we're developing a simple Web Socket server by Python for testing. |
| 09:14 | <tyoshino> | That's only server-side work we're doing for now. |
| 09:14 | <remysharp> | tyoshino: have you seen the obited.org project? it might cover some of what you're doing |
| 09:15 | <tyoshino> | Oh, really? Looking... |
| 09:18 | MikeSmith | looks around Michael Carter |
| 09:18 | <tyoshino> | I see. Maybe this one http://orbited.org/svn/orbited/branches/0.5/daemon/orbited/websocket.py |
| 09:18 | <MikeSmith> | tyoshino: talk to Michael Carter |
| 09:18 | <MikeSmith> | wherever he is |
| 09:19 | <MikeSmith> | there was a period of time when he was on #whatwg quite a bit |
| 09:19 | <MikeSmith> | but that's been a while |
| 09:19 | <tyoshino> | ok. thanks for the info. |
| 09:19 | <tyoshino> | thanks, mike and remysharp. |
| 09:34 | <jgraham> | hsivonen: I dunno I rather like cute pictures of hedgehogs |
| 09:34 | <jgraham> | although Architecture of the World Wide Web does appear half way down the first page for me |
| 09:36 | <MikeSmith> | Hixie: so I know that the summary attribute is now listed in "Conforming but obsolete features" section, but I see that the "Content attributes" field for the table element still just has only "Global attributes", without "summary" |
| 09:36 | <Hixie> | yeah the top half of the spec doesn't list any of the things that trigger teh warnings |
| 09:37 | <MikeSmith> | I see |
| 09:37 | <gsnedders> | Did element.spellcheck previously return true/false (as booleans?) |
| 09:38 | <Philip`> | jgraham: http://img.dailymail.co.uk/i/pix/2007/08_03/hedgehogSOLENT2708_800x495.jpg |
| 09:38 | <gsnedders> | Did Philip`really just drag this channel down to the lows of the Daily Mail? |
| 09:39 | <gsnedders> | gsnedders: yes |
| 09:39 | <MikeSmith> | Hixie: so is it accurate to now say that in the current draft, "the summary attribute on the table element is now valid, with a requirement for validators to warn that it is obsolete"? |
| 09:39 | <Philip`> | gsnedders: Sorry, I was just following the link from http://www.fupenguin.com/2009/02/clearly-lemurs-have-zero-personality.html :-( |
| 09:41 | <MikeSmith> | my daughter says my mustache makes me look like a ハリネズミ、which I think is same as hedgehog |
| 09:41 | <jgraham> | Initially I assumed that the title of that blog was some sort of anti-linux rant |
| 09:42 | <Philip`> | jgraham: No, it's just anti-penguin |
| 09:44 | <Hixie> | gsnedders: yes |
| 09:44 | <Hixie> | MikeSmith: it's accurate, though it's not how i would put it :-) |
| 09:44 | <gsnedders> | Hixie: I already answered myself. |
| 09:44 | <MikeSmith> | Hixie: OK |
| 09:44 | <Hixie> | gsnedders: i was answering your earlier question |
| 09:45 | <gsnedders> | Hixie: So was I. |
| 09:45 | <Hixie> | ok |
| 09:45 | <Hixie> | i thought you were answering your Philip` question |
| 09:45 | <MikeSmith> | Hixie: how would you word it? |
| 09:45 | <Hixie> | "The summary attribute is obsolete. Use one of these many other techniques instead." |
| 09:46 | <MikeSmith> | I can see that's accurate, but less precise |
| 09:47 | <jgraham> | MikeSmith: It is more helpful for authors though |
| 09:47 | <MikeSmith> | jgraham: it's missing a piece of information, which is that the attribute is also "conformant" |
| 09:48 | <Hixie> | MikeSmith: personally i'm fine with not mentioning that :-) |
| 09:49 | <jgraham> | I didn't disagree that it was less precise. But given a binary choice between thw two formulations I would go with the one that gives the best advice on how to produce a useful document, not on how to produce a conformant document |
| 09:50 | <jgraham> | (in practice such a binary choice is not necessary) |
| 09:51 | <MikeSmith> | people are going to figure it out anyway |
| 09:51 | <MikeSmith> | and describe it in their own terms |
| 09:51 | <MikeSmith> | regardless of how we put it |
| 09:51 | <jgraham> | How to produce a useful document or the fact that summmary is conforming? |
| 09:56 | <MikeSmith> | jgraham: that summary is listed in the spec as a "Conforming but obsolete feature" |
| 09:56 | <jgraham> | MikeSmith: All the more reason to focus we we write on how to produce a useful document then |
| 09:57 | <gsnedders> | "content attribute" means an element.getAttribute() attribute? |
| 09:59 | <Philip`> | gsnedders: Yes - content attributes are attributes in the DOM, while DOM attributes are properties in JS |
| 09:59 | <Philip`> | (I think) |
| 10:00 | <gsnedders> | :P |
| 10:23 | <mookid> | the Accept header drama continues! http://newmediacampaigns.com/page/webkit-team-admits-accept-header-error#comments :D |
| 10:25 | <mookid> | I didn't include a 'full' use case though so I'm probably wrong |
| 10:25 | <mookid> | -_- |
| 10:26 | <othermaciej> | mookid: is that your blog? |
| 10:26 | <mookid> | no that's my comment |
| 10:26 | <mookid> | I'm mike |
| 10:26 | <mookid> | KrisJordan is some other dude building a PHP REST framework |
| 10:26 | <mookid> | smart guy |
| 10:27 | <mookid> | I'm the one with the charming smile |
| 10:27 | <Hixie> | the Accept header (and conneg in general) is such a bad idea |
| 10:27 | <mookid> | Hixie: |
| 10:27 | <mookid> | care to elaborate? |
| 10:27 | <othermaciej> | I must say that lengthy blog posts are not my favorite way to receive bug reports |
| 10:27 | <Hixie> | it's hugely complex |
| 10:27 | <mookid> | good lord |
| 10:27 | <Hixie> | and it doesn't really do anything useful |
| 10:28 | <mookid> | Hixie: read my response |
| 10:28 | <Hixie> | it's confusing to people |
| 10:28 | <mookid> | caching is useful. |
| 10:28 | <mookid> | layering is useful |
| 10:28 | <othermaciej> | also turning my reddit comment into a pretext for a second equally lengthy blog post is also kinda weak |
| 10:28 | <mookid> | uniform resource identifiers are important |
| 10:28 | <Hixie> | conneg screws up caching, too |
| 10:28 | <mookid> | no it doesnt |
| 10:28 | <mookid> | that's what the Vary header is for |
| 10:28 | <mookid> | know about that? |
| 10:28 | <Hixie> | Vary is another disaster :-) |
| 10:28 | <othermaciej> | multiple representations for one URI is not really a useful feature IMO |
| 10:29 | <MikeSmith> | mookid: hey! long time no see |
| 10:29 | <mookid> | yo dude |
| 10:29 | <mookid> | =) |
| 10:29 | <othermaciej> | generally using multiple URIs is better |
| 10:29 | <Hixie> | yeah |
| 10:29 | <mookid> | did you even read my comment? |
| 10:29 | <othermaciej> | so I guess I agree with Matthe Markus |
| 10:29 | <Hixie> | i wish HTTP had never introduced conneg |
| 10:29 | <mookid> | Hixie: do you know anything about REST at all? |
| 10:30 | <othermaciej> | haven't read yours yet |
| 10:30 | <othermaciej> | I must admit that REST is a belief system I don't fully comprehend |
| 10:30 | <Hixie> | yeah, i'm not a big fan of REST |
| 10:30 | <mookid> | well |
| 10:30 | <mookid> | if you aren't |
| 10:30 | <mookid> | that's frankly irrelevant |
| 10:30 | <mookid> | and the fact that one ofthe key architects of HTTP |
| 10:30 | <Hixie> | you brought it up :-) |
| 10:30 | <mookid> | defined REST |
| 10:30 | <jgraham> | Just because something has a fancy acyronym and a PhD thesis doesn't mean that it's right |
| 10:30 | <mookid> | it's can't be wrong |
| 10:30 | <othermaciej> | Roy Fielding is kind of a blowhard |
| 10:31 | <mookid> | he wrote the fecking RFC |
| 10:31 | <gsnedders> | mookid: Appeal to authority doesn't mean it is right. |
| 10:31 | takkaria | giggles a little |
| 10:31 | <mookid> | it's nothing to do with authority and everything to do with common fecking sense |
| 10:31 | <Hixie> | i'm all for using methods on URLs instead of doing everything using POST data |
| 10:31 | <mookid> | the simpole fact is |
| 10:31 | <mookid> | we can live together |
| 10:31 | <mookid> | with you using URIs badly |
| 10:31 | <mookid> | and me using them properly |
| 10:31 | <mookid> | if you just include the mechanism in the spec |
| 10:31 | <Hixie> | but IMHO using the same URL for multiple "representations" is just taking it too far |
| 10:31 | <MikeSmith> | Kris Jordan.. I think we've discovered who Mr. Last Week is. some similarities there |
| 10:31 | <Hixie> | in the other direction |
| 10:31 | <jgraham> | takkaria: Oh bollocks I forgot the DVDs again |
| 10:32 | <takkaria> | jgraham: no worries, I'll live :) |
| 10:32 | <jgraham> | Sorry |
| 10:32 | <othermaciej> | MikeSmith: nah, Kris Jordan may think his pet bug is the most important in the universe, but he doesn't descend into the scatological |
| 10:32 | <mookid> | Hixie: HTTP provides the mechanism whether you like it or not, I should be able to use it - and the only reason I won't in HTML is because you don't *think* it's right |
| 10:33 | <mookid> | and the only reason you can provide is |
| 10:33 | <Hixie> | i guess i'll have to add HTTP to the list of specs I have to go fix once I'm done fixing HTML :-) |
| 10:33 | <mookid> | 'the client and intemediary implementations don't work properly' |
| 10:33 | <mookid> | well they don't work properly |
| 10:33 | <Hixie> | that's not the only reason |
| 10:33 | <mookid> | becausenobody uses them |
| 10:33 | <Hixie> | i just think it's a bad idea |
| 10:33 | <mookid> | because they arent practical at the moment |
| 10:33 | <mookid> | because HTML and browsers are crap |
| 10:34 | <mookid> | it's a self-fulfilling prophecy of The Stupid(tm) |
| 10:34 | <Hixie> | the whole conneg thing, and the multiple files per URL thing, are IMHO unnecessary complexity that don't really solve any important problems that can't be solved more easily in simpler, already-usable manners |
| 10:34 | <mookid> | did you read my comment |
| 10:34 | <mookid> | about layering? |
| 10:34 | <Hixie> | yes |
| 10:35 | <jgraham> | takkaria: What if someone were to try and shoot you whilst you were walking home and, had you had the DVDs, they would have stopped the bullet? |
| 10:35 | <mookid> | well how do you suppose that you fix that issue of cache invalidation? |
| 10:35 | <othermaciej> | I read your comment about caching |
| 10:35 | <othermaciej> | it's not really applicable to individual tweets, since they are not supposed to change |
| 10:35 | <takkaria> | jgraham: hmm, I'll just have to put my ipod where I would have put the DVDs, I imagine it's thickert anyhow :) |
| 10:35 | <othermaciej> | it might apply to a twitter *feed* |
| 10:36 | <mookid> | ok ok but let's hypothetically suppose that twitter allowed you to update a tweet |
| 10:36 | <othermaciej> | but PUT would not be the right way to update a twitter feed, and it would be wrong to give a twitter feed a long cache lifetime |
| 10:36 | <mookid> | which is perfectly feasible and useful functionality |
| 10:36 | <Hixie> | mookid: what you describe doesn't help either -- if one person has downloaded the tweet, and you PUT to it, how does their cache get invalidated? |
| 10:36 | <mookid> | that's client side caching |
| 10:36 | <mookid> | not intemedirary caching |
| 10:36 | <othermaciej> | if tweets can be updated at any time, they can't have a long cache lifetime |
| 10:36 | <Hixie> | mookid: if you have a different intemedirary [six] cache, it is |
| 10:37 | <mookid> | I'm talking server side reverse proxy caches.. you know.. those things that are SUPER efficient |
| 10:37 | <othermaciej> | (intermediary caches and client caches follow the same expiration rules) |
| 10:37 | <mookid> | and allow you to SCALE an application |
| 10:37 | <mookid> | when you're actually building REAL applications |
| 10:37 | <Hixie> | the server-side caches can do whatever you want, you control them |
| 10:37 | <mookid> | instead of hypothetical use cases |
| 10:37 | <Philip`> | ("six"?) |
| 10:37 | <mookid> | YES |
| 10:37 | <Hixie> | sic, sorry |
| 10:37 | <mookid> | Hixie: yeah you can |
| 10:37 | <mookid> | and if you have to teach it about URI structures |
| 10:37 | <mookid> | and dot notation |
| 10:37 | <Hixie> | mookid: so when you PUT to foo.bar, clear the cache for foo.* |
| 10:37 | <mookid> | it's coupled to your appp |
| 10:38 | <mookid> | that's tight coupling and that's bad news |
| 10:38 | <othermaciej> | if you have multiple reverse proxy servers, you need custom logic to keep their caches valid |
| 10:38 | <othermaciej> | if you have exactly one, that doesn't sound very scalable to me |
| 10:38 | <Hixie> | mookid: how do you propose to invalidate the cache for the feeds when you PUT to the tweet? |
| 10:38 | <jgraham> | Philip`: I think you meant "six [sex]" |
| 10:38 | <mookid> | Hixie: what? any PUT would invalidate all caches for that resource |
| 10:39 | <Hixie> | mookid: the feed is a different resource |
| 10:39 | <othermaciej> | the feed is a different resource than any individual tweets in it |
| 10:39 | <mookid> | yeah..? |
| 10:39 | <othermaciej> | but it depends on the content of all tweets in it |
| 10:39 | <mookid> | a feed should be a series of links |
| 10:39 | <Hixie> | so how would it get invalidated when you update the tweet? |
| 10:39 | <mookid> | if you can't design hypermedia systems properly that's not my problem |
| 10:39 | <Hixie> | or when you add a new tweet? |
| 10:39 | <mookid> | well |
| 10:39 | <mookid> | look |
| 10:39 | <Philip`> | mookid: So if you want to read a feed containing n messages, you'd have to make n+1 HTTP requests? |
| 10:40 | <Hixie> | i'm quite capable of designing a hypermedia system, i'm just asking you how you would do it since you seem to want a particular weird feature that as far as i can tell, doesn't work |
| 10:40 | <mookid> | feed : [ "/tweet/123", "/tweet/1234", etc.. ] |
| 10:40 | <mookid> | that's my feed |
| 10:40 | <othermaciej> | twitter would be pretty useless if instead of a stream of tweets, the UI was a page of links to tweets |
| 10:40 | <mookid> | oh look |
| 10:40 | <mookid> | HYPERMEDIA |
| 10:40 | <Philip`> | mookid: That doesn't seem very scalable |
| 10:40 | <mookid> | that's how hyperlinks work |
| 10:40 | <mookid> | and it's very scalable |
| 10:40 | <Hixie> | you're not answering the question |
| 10:40 | <mookid> | yes it is |
| 10:41 | <mookid> | you're asking me how it would invalidate the feed if you updated |
| 10:41 | <mookid> | if wouldn't |
| 10:41 | Philip` | can't imagine how n+1 requests vs 1 request is scalable, particularly since n might get very large |
| 10:41 | <mookid> | that's the trade off of REST vs. RPC |
| 10:41 | <Hixie> | mookid: how would a DELETE to a tweet invalidate the cache for the feed? |
| 10:41 | <othermaciej> | so basically you are saying that the UI of twitter is intrinsically not RESTful? |
| 10:41 | <mookid> | exactly |
| 10:41 | <othermaciej> | (since it is a page of content, not a page of links) |
| 10:42 | <mookid> | it's semi restful |
| 10:42 | <othermaciej> | REST sounds like a huge waste of time then |
| 10:42 | <Hixie> | sounds to me like mookid just proved that REST is a bad idea |
| 10:42 | <Hixie> | i'm impressed |
| 10:42 | <mookid> | what? |
| 10:42 | <othermaciej> | if it can't be used to build useful apps like Twitter |
| 10:42 | <mookid> | IT CAN |
| 10:42 | <mookid> | it's just isnt |
| 10:42 | <Philip`> | There's a difference between being "a huge waste of time"/"a bad idea", and being unsuitable for some subset of use cases |
| 10:42 | <othermaciej> | if you change the UI of Twitter to be useless it can |
| 10:43 | <Hixie> | i'm still curious about how a DELETE to a tweet would invalidate the cache for the feed |
| 10:43 | <Philip`> | I bet a cheese sandwich is intrisically not RESTful either |
| 10:43 | <othermaciej> | but a page of links to dozens of 140 character messages would be a poor UI |
| 10:43 | <mookid> | it's hillarious that you todgers have such a problem with the style used IN THE DESIGN OF THE HTTP PROTOCOL |
| 10:43 | <mookid> | hello...?! |
| 10:43 | <takkaria> | it does seem pretty mad to suggest performing n HTTP requests for the feed page of Twitter, when each tweet probably contains fewer characters than teh HTTP request header |
| 10:43 | <othermaciej> | many aspects of the HTTP protocol are kind of useless in practice |
| 10:43 | <Hixie> | mookid: don't worry, we have huge problems with the design of the URI and HTML specs too :-) |
| 10:43 | <mookid> | othermaciej: the reason for tha tis because browsers and HTML are crap |
| 10:44 | <mookid> | not because there's anything wrong wiht HTTP |
| 10:44 | <othermaciej> | personally I have a bone to pick with TCP as well |
| 10:44 | <othermaciej> | and IP |
| 10:44 | <Hixie> | i thought TCP was pretty good actually |
| 10:44 | <Hixie> | though i guess i don't know it as well as HTTP, HTML, and URIs |
| 10:44 | <Hixie> | DNS on the other hand is a disaster |
| 10:44 | <Hixie> | though not as bad as SMTP, which is epicly bad |
| 10:44 | <othermaciej> | the main design problem is that it ramps up so slowly and uses excess round trips per connection |
| 10:44 | <othermaciej> | although TCP is mostly good |
| 10:45 | <MikeSmith> | TCP is not the best thing for high packet-loss networks, like mobile-phone networks |
| 10:45 | <mookid> | othermaciej: that wouldn't be a poort UI, that would be a RIA |
| 10:45 | <Hixie> | so mookid, could you let me know how a DELETE to a tweet would invalidate the cache for the feed? |
| 10:45 | <mookid> | why don't you ask the HTTP team that question |
| 10:46 | <Hixie> | they HTTP team isn't telling me that I should add features to HTML |
| 10:46 | <Hixie> | s/they/the/ |
| 10:46 | <mookid> | no because they can't be bothered with these levels of pomposity I assume |
| 10:46 | olliej | is glad he has no knowledge of http, or in fact anything much below html :D |
| 10:46 | Philip` | is glad he doesn't even know anything about HTML |
| 10:46 | <olliej> | Philip`: actually i think i might be with you at that |
| 10:47 | <othermaciej> | olliej: nearly every part of the technology stack we work with is severely boned |
| 10:47 | <olliej> | Philip`: the dom isn't really html |
| 10:47 | <olliej> | othermaciej: i know :-( |
| 10:47 | olliej | stabs JS |
| 10:47 | <othermaciej> | I mean, I guess I can't complain much about Ethernet |
| 10:47 | <olliej> | and Canvas |
| 10:47 | <olliej> | and SVG |
| 10:47 | <Philip`> | Wires are a stupid idea, too |
| 10:47 | <Hixie> | mookid: well, let me know when you find an answer, since that seems to be a key part of your argument (namely that the reason you would use one URL is that it makes caching automatically work) |
| 10:47 | <olliej> | Philip`: we should have stuck with pigeons |
| 10:47 | <Philip`> | And who came up with the idea of atoms? |
| 10:47 | <othermaciej> | yeah but Ethernet scales to wireless networks |
| 10:48 | <mookid> | actually DELETE's are pretty rare |
| 10:48 | <Hixie> | not for twitter posts they're not :-) |
| 10:48 | <mookid> | the technical answer is you'd DELETE the tweet and PUT a new representation of the feed minus the link |
| 10:49 | <Hixie> | the _client_ has to update the feed?! |
| 10:49 | <othermaciej> | how can the client safely PUT the feed when it doesn't know the server's latest state? |
| 10:49 | <Philip`> | Do you need some kind of concurrency control for that? |
| 10:49 | <takkaria> | hah |
| 10:49 | <Hixie> | how about the feed of other users who are subscribed to you? |
| 10:49 | <Hixie> | surely hte client wouldn't be allowed to PUT to those |
| 10:50 | <mookid> | Hixie: I didn't say what was PUT'ing the feed .. :) |
| 10:50 | <mookid> | the server can make that call |
| 10:50 | <mookid> | the server handling the DELETE |
| 10:50 | <mookid> | can make the PUT call |
| 10:50 | <mookid> | but you'd know that |
| 10:50 | <Hixie> | why can't the server make the call to PUT the new .json and .xml versions then? |
| 10:50 | <othermaciej> | the server should PUT to itself to update its own reverse proxy? |
| 10:50 | <mookid> | obviously |
| 10:50 | <mookid> | othermaciej: right |
| 10:50 | <mookid> | it would address it via it's URI |
| 10:50 | <Hixie> | sounds like you just solved your own problem and don't need conneg anymore! |
| 10:50 | <mookid> | that's called a ... distributed system1 |
| 10:50 | <mookid> | !!! |
| 10:51 | <Hixie> | i'm glad i could help |
| 10:51 | <mookid> | no.. |
| 10:51 | <mookid> | look at the costs |
| 10:51 | <mookid> | on the DELETE |
| 10:51 | <mookid> | and on the update |
| 10:51 | <mookid> | think about it.. |
| 10:51 | <mookid> | *DING* |
| 10:51 | <Hixie> | i think that if you look at the costs it is blatently clear that nobody is ever going to implement what you describe |
| 10:51 | <Philip`> | Layering would be a nice concept if it actually worked |
| 10:51 | <mookid> | welcome to the real world ian |
| 10:52 | <mookid> | Hixie: I don't know what makes you so sure about that |
| 10:52 | <mookid> | look at JAX-RS |
| 10:52 | <mookid> | or any modern web framework |
| 10:52 | <mookid> | all going REST direction |
| 10:52 | <mookid> | all have HTTP client libraries |
| 10:52 | <Hixie> | mookid: ashton kutcher has over 2 million followers, if he does a DELETE, there's no way any sane implementation is going to do 2,000,000 PUTs to update his followers' feeds |
| 10:52 | <mookid> | that's client-side caching |
| 10:53 | <mookid> | that's completely different |
| 10:53 | <gsnedders> | mookid: No, it's not. |
| 10:53 | <mookid> | YES IT IS |
| 10:53 | <othermaciej> | it would be awesome if you could get the server to DDOS its own reverse proxy |
| 10:53 | <gsnedders> | mookid: My twitter.com/home is different to yours |
| 10:53 | <Hixie> | no i'm talking about the server-side "reverse proxy" cache of those people's feeds |
| 10:53 | <mookid> | yeah that's bad design |
| 10:53 | <gsnedders> | mookid: So how should personalized data appear? |
| 10:53 | <mookid> | twitter.com/home should not be the same for every user |
| 10:53 | <mookid> | twitter.com/user123/home ? |
| 10:53 | <Hixie> | mookid: however you do it, you still have to update the feed for each user |
| 10:53 | <mookid> | you're all for URIs |
| 10:53 | <mookid> | oh wait |
| 10:53 | <gsnedders> | But you still need to invalidate caches for 2,000,000 of those, which doesn't scale. |
| 10:54 | <mookid> | NO YOUR NOT! |
| 10:54 | <mookid> | that's utter nonsense and it's not like you've solved that by using a URIA |
| 10:54 | <mookid> | I'm talking about server side caching |
| 10:54 | <Hixie> | hey i'm just repeating what you said |
| 10:54 | <gsnedders> | But you said we should PUT a new feed representation |
| 10:54 | <othermaciej> | someone should launch a fully RESTful competitor to twitter, I can see it would have just automatically solved all their early scaling problems |
| 10:54 | <mookid> | to avoid hitting processors and persistent storage |
| 10:54 | <Hixie> | you said after we do a DELETE, the server should PUT to all the urls that are affected |
| 10:54 | <gsnedders> | And that's what we're doing |
| 10:55 | <mookid> | othermaciej: pretty much |
| 10:55 | <takkaria> | luckily, "being woefully inefficient" is not the same as "scaling well" |
| 10:55 | <mookid> | you do realise that the enterprise community is pretty much agreed that REST is the solution to their scalability and interop problems right? |
| 10:55 | <gsnedders> | mookid: We're talking about server side caching too. |
| 10:55 | <mookid> | and the latest Java API for REST development is entirely Accept header driven |
| 10:56 | <mookid> | no you arent |
| 10:56 | <mookid> | because a DELETE |
| 10:56 | <gsnedders> | We _are_. |
| 10:56 | <mookid> | would invalidate the cache |
| 10:56 | <mookid> | for EVERYONE |
| 10:56 | <mookid> | if it was server side |
| 10:56 | <mookid> | and polled |
| 10:56 | <gsnedders> | Yes, we're talking about that. |
| 10:56 | jgraham | wonders what the collary for godwins law that applies when someone mentions "enterprise" |
| 10:56 | <Hixie> | mookid: i'm just trying to understand why you need to share one URL between three resources so that they all get invalidated at once, when other resources still need to be invalidated and can't get the same effect. |
| 10:56 | <takkaria> | we're back to star trek again :) |
| 10:56 | <mookid> | Hixie: they don't need invalidating |
| 10:57 | <mookid> | because the collections contain hyperlinks |
| 10:57 | <mookid> | not the data itself |
| 10:57 | <Hixie> | mookid: so when ashton kutcher deletes a tweet, how does it get removed from my personal feed? |
| 10:57 | <Hixie> | assuming i were to follow ashton kutcher |
| 10:57 | <mookid> | you'd poll his feed and it'd have the link removed |
| 10:57 | <Hixie> | (i've no idea who ashton kutcher is, he's just a random name i picked from http://twitterholic.com/) |
| 10:57 | <gsnedders> | So we need to make more requests? |
| 10:57 | <mookid> | polling is how HTTP works |
| 10:58 | <Philip`> | jgraham: Kirk's Law? |
| 10:58 | <mookid> | unless you want to get into Comet and crap like that |
| 10:58 | <Hixie> | mookid: so i have to poll all the feeds of all the people i'm subscribed to every time i want to view my feed? |
| 10:58 | <jgraham> | Philip`: Add it to wikipedia |
| 10:58 | <Philip`> | Oh wait, takkaria already made the Star Trek connection :-( |
| 10:58 | <mookid> | Hixie: right |
| 10:58 | <othermaciej> | seems like you could just put a very short freshness lifetime on the feed and get the same effect |
| 10:58 | <Philip`> | while I was busy looking on Wikipedia to work out who was a captain of the Enterprise |
| 10:58 | <Hixie> | mookid: so when barack obama views his twitter feed, he has to do 773,210 HTTP requests? |
| 10:59 | <gsnedders> | mookid: I can currently get Twitter.com/home with all my followers in one request. You are proposing to make me have to do n+1 requests, where n is the number of tweets. When I have to pay over £100/MB from my phone, I want as little overhead as possible, and HTTP requests have an overhead. |
| 10:59 | <mookid> | that is ONE use case |
| 10:59 | <mookid> | and yes |
| 10:59 | <mookid> | that is how it would work |
| 10:59 | <mookid> | if it was RESTful |
| 11:00 | <jgraham> | gsnedders: When you are paying that puch you don't want to be browisng the web |
| 11:00 | <mookid> | yes 700k requests is ridiculous |
| 11:00 | <mookid> | but so is FOLLOWING 700k people |
| 11:00 | <Hixie> | it would be streeful, not restful, if a user had to make 773,210 HTTP requests each time they reloaded their feed |
| 11:00 | <Hixie> | stressful, rather |
| 11:00 | <mookid> | read^ |
| 11:00 | <Hixie> | it might be ridiculous, but it's what he does |
| 11:00 | <gsnedders> | mookid: Also, if REST is more efficient, how is making 700k requests more efficant than 1 request? |
| 11:01 | <Philip`> | (I don't think he personally reads all the content on his Twitter feed) |
| 11:01 | <mookid> | ok so we've establised people use twitter moronically because they have stupid policies |
| 11:01 | <mookid> | so |
| 11:01 | <Hixie> | robert scoble follows 101,915 people and he actually does read them, from what i understand |
| 11:01 | <mookid> | that means there is no situation where that would be useful? |
| 11:01 | <mookid> | no he reads his @'s I imagine |
| 11:01 | <Hixie> | that's still an impossible number of HTTP requests per reload |
| 11:01 | <mookid> | depends really |
| 11:01 | takkaria | watches the goalposts move, apparently of their own accord |
| 11:01 | <mookid> | layered architecture and all |
| 11:02 | <mookid> | have a non-cacheable feed resource which populates itself with internal HTTP calls |
| 11:02 | <othermaciej> | I think the point is, if you think about a real app and not a toy problem, the benefit of cache invalidation of alternate representations of a resource on PUT/DELETE vanishes |
| 11:02 | <mookid> | is the best solution |
| 11:02 | <mookid> | well I'm in the real world doing this |
| 11:02 | <othermaciej> | because in general, you will have to invalidate dependent resources on a change |
| 11:02 | <mookid> | building servers/client/intemediaries |
| 11:02 | <Hixie> | even if we ignore the people who live on twitter, i follow 101 people, should i really have to do 101 HTTP requests to read my feed? |
| 11:03 | <Hixie> | that seems crazy to me |
| 11:03 | <Hixie> | certainly not efficient |
| 11:03 | <mookid> | hence my comment about layering |
| 11:03 | <hsivonen> | Hixie: If the document has a script-created parser and a script inserts an external script to the DOM, when the newly-inserted script loads, should it be able to do document.write without implying document.open? |
| 11:03 | <mookid> | and a time cached/non-cacheable feed resource |
| 11:03 | <othermaciej> | and if you can update dependent resources, then you could update alternate representations at different URIs |
| 11:03 | <gsnedders> | You said enterprise would benefit from it, and they quite often control their entire stack from server down to client, so why can't you get any enterprises to use something with @accept? |
| 11:03 | <Hixie> | hsivonen: yes (it'll write to the end, iirc) |
| 11:04 | <gsnedders> | mookid: If there really is that much to gain, I would expect that to have been done by now. |
| 11:04 | <mookid> | mmm |
| 11:04 | <mookid> | it's happening as we speak |
| 11:04 | <hsivonen> | Hixie: OK. I wonder if Gecko's parser key infrastructure lets me do that right easily... |
| 11:04 | <mookid> | loads of CDNs are RESTful using intemediaries |
| 11:04 | <mookid> | and HTTP messages |
| 11:05 | <mookid> | but hey - that's only the real world |
| 11:05 | <mookid> | I wouldn't worry about that |
| 11:05 | <mookid> | just make broad sweeping statements and assumptions |
| 11:05 | <mookid> | that's probably good enough |
| 11:06 | <takkaria> | well, if things are going to happen anyway, why are you complaining so bitterly? :) |
| 11:06 | <mookid> | ... |
| 11:06 | <mookid> | HTTP content-negotiation isn't practical *until* hypermedia formats support it |
| 11:06 | <mookid> | well it's semi-practical |
| 11:06 | <mookid> | it's a lot harder than it needs to be |
| 11:07 | <Hixie> | HTTP content-negotiation isn't a great idea anyway, as we've just discussed, it doesn't really solve any problems that aren't easily solved in another way anyway |
| 11:07 | <Hixie> | life would be better if we could just drop it altogether |
| 11:07 | <mookid> | it's irrelevant that's subjective assumption on your part |
| 11:07 | <hsivonen> | Hixie: I think I'll try to hack an approximation for now and see if it accidentally does the right thing... |
| 11:07 | <mookid> | and an ignorant one at that |
| 11:08 | <Hixie> | i don't know if i'd go around telling people they were ignorant if i was the one saying that updateing a feed should require hundreds of requests... |
| 11:08 | <mookid> | ... |
| 11:08 | <mookid> | . |
| 11:09 | <othermaciej> | Hixie: that's the scalability benefit of RESTful design |
| 11:09 | <othermaciej> | it scales you from one request to hundreds or even thousands |
| 11:09 | <othermaciej> | like DUH |
| 11:09 | <mookid> | *sigh* |
| 11:09 | <mookid> | do you have any idea how stupid that looks? |
| 11:10 | jgraham | can imagine this whole conversation being played out with s/conneg/WS-*/ |
| 11:10 | <mookid> | it doesn't require hudnreds of requests it requires one to the tweet resource.. which will invalidate the SERVER SIDE CACHE |
| 11:10 | hsivonen | wonders if Scoble has client-side twitter filters |
| 11:10 | <mookid> | which the clients are polling anyway |
| 11:11 | <mookid> | this is stupid anyway the tweet is used as an example of a resource with multiple representations |
| 11:11 | <mookid> | not a perfect candidate system for RESTful architecture |
| 11:11 | <Hixie> | what's a perfect candidate system for RESTful architecture then? |
| 11:11 | <Hixie> | maybe we should be looking at perfect exampels |
| 11:11 | <Hixie> | rather than flawed ones |
| 11:12 | <Hixie> | since flawed ones would naturally not lead us to appreciate the full power of the REST system |
| 11:12 | <mookid> | why don't you go read up |
| 11:12 | <jgraham> | From my position of ignorance twitter looks like more or less the simplest type of system that has to scale |
| 11:12 | <othermaciej> | most web apps of interest tend to have multiple resources depending on the same underlying piece of server-side data |
| 11:12 | <othermaciej> | jgraham: actually twitter has to propagate state changes to be reflected via many URIs, so it seems pretty hard to scale (and I gather that it was in fact hard) |
| 11:13 | <mookid> | there are elegant ways to solve that with REST I just can't be bothered, and it would be largely wasted on you anyway |
| 11:13 | <mookid> | I doubt you would understand it |
| 11:13 | <takkaria> | I don't get why some people need a metanarrative about the most pure way to build systems. surely, if you want to build a system, you just build it so it works and in as sane a way as you can manage? ther'es no need for religious devotion toward the one true way |
| 11:13 | <mookid> | I'm not claiming my way is best I'm just telloing you that the HTTP spec enables my method |
| 11:13 | <mookid> | and one of the things holding me back |
| 11:14 | <mookid> | is HTML |
| 11:14 | <mookid> | there's no reason we can't both have our own philosophies and solutions |
| 11:14 | <mookid> | you can ignore the attribute all together |
| 11:14 | <mookid> | and use as many URIs as you want |
| 11:14 | <mookid> | for whatever you want |
| 11:15 | <mookid> | so you're effectively denying me something that would be relatively simple to executre on the basis you don't "agree" |
| 11:15 | <mookid> | I think it's more likely that you don't "understand" but whatever |
| 11:15 | <jgraham> | othermaciej: Yeah I know it was hard to scale. I mean conceptually it's a pretty simple system, but maybe that's less relevant than the underlying difficulty of propogaing the tweets |
| 11:16 | <othermaciej> | it has a very simple UI, but not a very simple architecture |
| 11:16 | <mookid> | lol. |
| 11:16 | <mookid> | :) |
| 11:16 | <mookid> | you people. |
| 11:17 | <mookid> | hello people in the future reading this - I'm sorry. |
| 11:17 | <mookid> | I tried. |
| 11:18 | <jgraham> | othermaciej: Sure. |
| 11:18 | <othermaciej> | I'm trying to think of a real, popular Web app that doesn't have dependent resources as a major part of its functionality |
| 11:18 | <mookid> | ... |
| 11:18 | <mookid> | they're not dependant resources |
| 11:18 | <mookid> | they're representations of the same resource |
| 11:19 | <mookid> | hence why giving them separate resource identifiers is mal practice |
| 11:19 | <othermaciej> | mookid: I'm glad you psychically determined what I was talking about |
| 11:19 | <hsivonen> | what's the issue? cache-invalidating dependent resources without having to re-check cache consistency with the origin server? |
| 11:19 | <othermaciej> | now let me figure out how the reddit.com homepage is an alternate representation of the same resource as every article page |
| 11:20 | <mookid> | what? |
| 11:20 | <othermaciej> | hsivonen: there's not really an issue |
| 11:20 | <mookid> | make sense |
| 11:21 | <othermaciej> | hsivonen: the point of discussion, such as it is, is whether content negotiation is a useful feature that can solve real problems in the context of RESTful design |
| 11:21 | <jgraham> | hsivonen: The point of the discussion is to rehash the same discussion that we had on the same topic a while ago |
| 11:22 | <jgraham> | Withot any new information |
| 11:22 | <jgraham> | *Without |
| 11:22 | <mookid> | I don't really see what the problem is here - HTTP provides the mechanism and you're plain ignoring it |
| 11:22 | <othermaciej> | I've been told (though I didn't see it in the scrollback) that the motivation for bringing up this general topic is the desire for an <a accept=""> attribute so that you can control the Accept header the browser sends when following a link |
| 11:22 | <mookid> | right |
| 11:23 | <hsivonen> | I thought we already figured out that content negotiotion is mostly BS |
| 11:23 | hsivonen | digs up notes |
| 11:23 | <othermaciej> | hsivonen: mookid is not on board that particular train |
| 11:23 | <hsivonen> | Accept-Language: for content: FAIL; for UIs: just might work sometimes |
| 11:24 | <othermaciej> | <a accept=""> seems bad to me, because it means the linking resource has to have knowledge of which representations of the linked-to resource all possible UAs will want |
| 11:24 | <hsivonen> | Accept-Encoding: success but arguably an architectural flaw (compare with Transfer-Encoding) |
| 11:24 | <hsivonen> | Accept-Charset: pointless. obsoleted by UTF-8 |
| 11:24 | <hsivonen> | Accept: FAIL |
| 11:25 | <hsivonen> | Accept only works for PNG vs. GIF, but no one uses it that way |
| 11:25 | <othermaciej> | which seems flawed - the whole point of Accept is that different clients may prefer different representations |
| 11:25 | <mookid> | lol |
| 11:25 | <hsivonen> | Word document vs. HTML document vs. PDF depends on what the user is planning on doing next |
| 11:26 | <mookid> | this has to be one of the most ridiculous discussions I've ever had |
| 11:26 | <roc> | I can't believe you guys got sucked into this |
| 11:26 | <othermaciej> | mookid: we have found a point of agreement |
| 11:26 | <Philip`> | mookid: More ridiculous than the last time the same points were discussed? |
| 11:26 | <mookid> | possibly |
| 11:27 | <mookid> | at the end of the day - that attribute would not break anything you wanted to do, you could just ignore it and be none the wiser |
| 11:29 | <mookid> | you're making a descision on behalf of the entire human race |
| 11:29 | <othermaciej> | it seems to me that <a accept=""> violates the REST philosophy |
| 11:29 | <mookid> | ok well the Atom Publishing Protocol has a similar concept |
| 11:30 | <othermaciej> | a resource representation shouldn't be telling a client what representations of another resource it should prefer |
| 11:30 | <mookid> | why? |
| 11:30 | <hsivonen> | krijnh: "cision on behalf of the entire human race |
| 11:30 | <jgraham> | Curiously all decisions one makes affect the whole human race. |
| 11:30 | <hsivonen> | whoa |
| 11:30 | <hsivonen> | sorry |
| 11:31 | <mookid> | yeah but these descisions, unfortunately, have a large impact on the world |
| 11:31 | <othermaciej> | because the whole point of Accept is for the client to tell the server what representations it prefers |
| 11:31 | <mookid> | right |
| 11:31 | <mookid> | so if I have an HTML page |
| 11:31 | <othermaciej> | if the server is deciding what representation should be sent, it doesn't need to tell the client to tell it what to send, it can just send it |
| 11:31 | <mookid> | which provides links to a resource and says to the user 'html, xml, or json' |
| 11:32 | <mookid> | the user clicks it |
| 11:32 | <mookid> | they should probably get the right representation |
| 11:33 | <mookid> | othermaciej: there's no way of doing that in stateless system |
| 11:33 | <mookid> | that's what headers are for. |
| 11:47 | hsivonen | wishes there were some kind of moratorium on codec debates |
| 11:47 | <Hixie> | there is a moratorium in the whatwg on adding to threads without adding new information |
| 11:48 | <hsivonen> | Hixie: not very effective, it seems :-( |
| 11:50 | <roc> | Maik Merten just added some information |
| 11:50 | <hsivonen> | great |
| 11:51 | <hsivonen> | hmm. I'm now very confused with http://hixie.ch/tests/adhoc/dom/level0/write/005.html |
| 11:51 | <hsivonen> | I tweaked things a bit and how I get behavior that looks like the old Gecko behavior even though I didn't mean to do so |
| 12:09 | <Lachy> | does anyone know what problem some people want solved by introducing <a href="..." coords="...">...</a> for image maps? |
| 12:10 | <Hixie> | it'd be a better design than <area> if we didn't have <area> already |
| 12:10 | <Lachy> | yeah, sure, but given that we do have area, what problem would be solved by it? |
| 12:12 | hsivonen | get an epiphany on how to fix document.write from external non-parser-inserted scripts when there's a script-created parser |
| 12:12 | <hsivonen> | *gets |
| 12:13 | <hsivonen> | (or is it "has". I get my idiomatic verbs wrong) |
| 12:16 | <MikeSmith> | hsivonen: "has" I guess |
| 12:16 | <hsivonen> | MikeSmith: ok |
| 12:22 | <gsnedders> | Hmm, when parsing innerHTML, if the context node is just root, when resetting the insertion mode it is set to "After head" |
| 12:22 | <gsnedders> | How is there no body created? |
| 12:23 | <gsnedders> | Oh, duh |
| 13:18 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/170 |
| 13:24 | <jgraham> | Red in all current browsers green (and two body elements) with HTML5 |
| 13:27 | <gsnedders> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/171 is a bit more interesting |
| 13:30 | <Lachy> | the HTML5 approach certainly makes sense. |
| 13:31 | <hsivonen> | jgraham: the HTML5 behavior is desirable for off-the-main-thread parsing |
| 13:32 | <Lachy> | unless there are cases where sites are relying on the behaviour of current browsers for this case, the HTML5 behaviour makes a lot more sense. |
| 13:33 | <jgraham> | hsivonen: having two body elements seems bad though. It also seems possible that it is a compat issue\ |
| 13:33 | <hsivonen> | jgraham: IIRC, we resolved as INVALID a bug report of similar nature in Gecko |
| 13:34 | <jgraham> | In what sense similar? and for what? The HTML5 parser? |
| 13:34 | <hsivonen> | jgraham: https://bugzilla.mozilla.org/show_bug.cgi?id=493882 |
| 13:34 | <hsivonen> | jgraham: not with the HTML5 parser |
| 13:36 | <jgraham> | hsivonen: I'm not against the HTML5 behaviour if it doesn't break sites |
| 13:37 | <Lachy> | this makes less sense to me. It's equivalent to the previous test, except that it uses divs instead. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/172 |
| 13:37 | <Lachy> | yet in HTML5 Gecko, it only results in one div, not two |
| 13:39 | <hsivonen> | that's an interesting case |
| 13:39 | <hsivonen> | I wonder what's going on there |
| 13:40 | <jgraham> | It seems like it should end up with the first div as the previous sibling of the head element |
| 13:40 | <jgraham> | Oh, no wait... |
| 13:42 | <jgraham> | When the innerHTML runs, it should remove the original <body> from the DOM and replace it with whatever the innerHTML algorithm produces |
| 13:43 | <jgraham> | Because subsequent operations in the original parser don't read from the DOM but from the sooe with the original body, the elements never end up in the DOM |
| 13:44 | <jgraham> | sooe == stack of open elements |
| 13:44 | <gsnedders> | (apart from the html element which is already in the DOM) |
| 13:57 | <Philip`> | Does any document define an error-recovery algorithm for decoding UTF-8? |
| 14:03 | <Lachy> | Philip`, doesn't the UTF-8 spec define something about replacing invalid sequences of octets with U+FFFD? What else do you need? |
| 14:04 | <hsivonen> | Lachy: how long is a sequence |
| 14:04 | <hsivonen> | Lachy: that's the question |
| 14:05 | <zcorpan> | Lachy: does the UTF-8 spec define that? |
| 14:05 | <Lachy> | hsivonen, I thought that was defined, though my knowledge of UTF-8 parsing is very limited |
| 14:06 | <hsivonen> | Philip`: you need the UTF-8 torture test from Markus Kuhn's site |
| 14:07 | <hsivonen> | Philip`: assume it's the spec :-/ |
| 14:13 | jgraham | guesses that there is a reasonable chance that Philip` knows Marcus Kuhn personally |
| 14:13 | gsnedders | wonders who Marcus Kuhn is (apart from someone in CS at Cam) |
| 14:14 | <jgraham> | gsnedders: a tattoo artist: http://www.marcuskuhn.com/ |
| 14:14 | <Philip`> | s/Marcus/Markus/ :-p |
| 14:14 | Philip` | attended security and Unix lectures by him |
| 14:16 | <Lachy> | wow, a tattoo artist that also gives talks on security and Unix on the side? :-) |
| 14:36 | <gsnedders> | I spy with my little eye something beginning with j |
| 14:36 | <gsnedders> | Now I can't see it! |
| 14:39 | <Lachy> | gsnedders, how can you play a game of I spy, when you can't actually see the thing? |
| 14:40 | <Lachy> | but since guessing games are fun, was it a jelly bean? |
| 14:40 | <gsnedders> | Well, I could see it at the time. |
| 14:41 | <gsnedders> | It just moved. |
| 14:41 | <Philip`> | Is it a jelly? |
| 14:42 | <gsnedders> | No |
| 14:43 | jgraham | thinks he is more of a he than an it |
| 14:43 | <jgraham> | Or rather a him |
| 14:43 | <gsnedders> | Hmm, maybe |
| 14:43 | gsnedders | turns to face the tyranny |
| 14:44 | <gsnedders> | (and go to the bin) |
| 14:46 | <Lachy> | gsnedders, was it jgraham? |
| 14:46 | <gsnedders> | Yes. |
| 14:46 | <Lachy> | woo hoo :-) |
| 15:57 | <gsnedders> | hsivonen: see these two, and the diff in DOMs: |
| 15:57 | <gsnedders> | http://livedom.validator.nu/?%3C!doctype%20html%3E%0D%0A%3Ctitle%3EMissing%20closing%20tag%20on%20IMG%3C%2Ftitle%3E%0D%0A%3Cp%20id%3D%22status%22%3EFAIL%20(Script%20did%20not%20run)%3C%2Fp%3E%0D%0A%3Cp%3E%0D%0A%20%20%20%20%3Ca%20href%3D%22%22%3E%3Cspan%3E%3C%2Fspan%3C%2Fa%3E%0D%0A%3C%2Fp%3E%0D%0A%0D%0A%3Cp%3EThis%20is%20filler%20text.%3C%2Fp%3E |
| 15:57 | <gsnedders> | http://livedom.validator.nu/?%3C!doctype%20html%3E%0D%0A%3Ctitle%3EMissing%20closing%20tag%20on%20IMG%3C%2Ftitle%3E%0D%0A%3Cp%3E%0D%0A%20%20%20%20%3Ca%20href%3D%22%22%3E%3Cspan%3E%3C%2Fspan%3C%2Fa%3E%0D%0A%3C%2Fp%3E%0D%0A%0D%0A%3Cp%3EThis%20is%20filler%20text.%3C%2Fp%3E |
| 16:01 | <gsnedders> | I think the one with p@id is right, and the other is wrong. |
| 22:28 | <Hixie> | http://www.brucelawson.co.uk/2009/html-5-is-a-mess/#comment-618907 that's a true story :-) |
| 22:30 | ezyang | bows in deference |
| 22:36 | Hixie | is starting to come to the conclusion that enough people think footers should be able to contain sections that we should just go ahead and allow it |
| 22:36 | <Hixie> | (sigh) |
| 22:45 | <hober> | hmm |
| 22:45 | <hober> | so <footer> would basically be for any back-matter? |
| 22:46 | <ezyang> | Mmm, I'm not quite sure I would call it back-matter |
| 22:47 | <hober> | like rfc2629bis' <back> |
| 22:56 | <MikeSmith> | Hixie: do that and <footer> will lose any real distinction from <section> except in name |
| 22:56 | <MikeSmith> | same content model, just different name |
| 22:56 | <MikeSmith> | maybe that's what people actually want |
| 22:58 | <ezyang> | you would think that footer would be fairly unambiguous |
| 22:59 | <MikeSmith> | ezyang: people use the same names for different things |
| 22:59 | <Hixie> | MikeSmith: <section> is in the outline, that's the big difference |
| 22:59 | <MikeSmith> | it seems like the general pattern that's may be emerging is that trying to be helpfully prescriptive in the spec about constraints on the content models of the structural elements is, in practice, maybe not going to be helpful |
| 22:59 | <ezyang> | Yeah, though I thought the web design community had formed a consensus on the design pattern of the "header" and the "footer" |
| 22:59 | <MikeSmith> | Hixie: can you imagine that somebody might next ask, why is footer not in the outline algorithm? |
| 23:00 | <Hixie> | MikeSmith: they haven't asked that for <header> |
| 23:00 | <Hixie> | basically this would make <header> and <footer> symmetric |
| 23:00 | <MikeSmith> | ezyang: I don't think the web design community has formed a consensus on anything. any single thing. |
| 23:00 | <ezyang> | :-/ Very possible. |
| 23:00 | <MikeSmith> | Hixie: symmetry is good. it makes things simpler for people |
| 23:01 | <MikeSmith> | ezyang: and Web designers may have different notions of what a footer is than, say, people who design outline algorithms |
| 23:02 | <ezyang> | I'm pretty sure they don't think footers go in outline algorithms. |
| 23:03 | <MikeSmith> | ezyang: I'm pretty sure some don't know what an outline algorithm is, and might not even care if they did know. |
| 23:03 | <ezyang> | "semantics" |
| 23:04 | <hober> | consider the site footer here: http://www.powazek.com/2005/09/000537.html |
| 23:04 | MikeSmith | looks |
| 23:04 | <ezyang> | Yeah. Totally not appropriate in the outline algo |
| 23:04 | <hober> | I can imagine the blog post above marked up in an <article> |
| 23:05 | <hober> | but I can imagine this footer as <footer><section><h2>The Fine Print</h2>...</section>...</footer> |
| 23:05 | <MikeSmith> | hober: to me, the footer is the just part that has derek (at) powazek (dot) com in the left column |
| 23:05 | <MikeSmith> | the Fine Print part is a sectin |
| 23:05 | <MikeSmith> | section |
| 23:05 | <MikeSmith> | with navigational content |
| 23:06 | <hober> | from that article: "So new here is a wayfinding footer - the kind of stuff that's usually ignored in sidebars. Will it help people stay on the site and surf around? I don't know - you tell me." |
| 23:07 | <hober> | I'm not saying I disagree, MikeSmith, but I think that's the crux of the confusion. People think of different things when they think of footers. |
| 23:07 | <hober> | I can imagine Derek's footer (the big one) participating in *the page*'s outline |
| 23:07 | <hober> | but not *the article*'s outline |
| 23:09 | <MikeSmith> | hober: agreed that it's clear people think of different things |
| 23:09 | <MikeSmith> | i'd suspect most people would call that a footer |
| 23:10 | <MikeSmith> | to me, it could just as well be a nav |
| 23:11 | <MikeSmith> | the physical placement of that content in the footer seems to me arbitrary |
| 23:11 | <MikeSmith> | at the footer of the page, I mean |
| 23:12 | <MikeSmith> | it could be presented as a pop-up |
| 23:13 | <MikeSmith> | I guess I would myself tend to think of footer content as something that makes the most sense at the end of the document flow |
| 23:14 | <MikeSmith> | like the stuff that comes at the very end of a movie |
| 23:14 | <MikeSmith> | not the full credits that roll by |
| 23:14 | <MikeSmith> | but just the last frame |
