/irc-logs / w3c / #webapps / 2008-12-03 / end
Options:
- # Session Start: Wed Dec 03 00:00:00 2008
- # Session Ident: #webapps
- # [00:01] * Joins: heycam (cam@130.194.72.84)
- # [01:07] * Quits: aroben (aroben@71.58.119.193) (Connection reset by peer)
- # [01:59] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
- # [02:02] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [02:03] * Joins: harry (kcome@58.213.218.123)
- # [02:36] * Quits: marcos (marcos@87.196.201.242) (Quit: marcos)
- # [03:00] * Joins: marcos (marcos@87.196.201.242)
- # [03:03] * Quits: marcos (marcos@87.196.201.242) (Ping timeout)
- # [03:48] * Joins: marcos (marcos@87.196.201.242)
- # [04:25] * Quits: marcos (marcos@87.196.201.242) (Quit: marcos)
- # [04:32] * Joins: phenny (phenny@mcclure.w3.org)
- # [04:38] * Quits: phenny (phenny@mcclure.w3.org) (Client exited)
- # [06:45] * Quits: hober (ted@206.212.254.2) (Ping timeout)
- # [07:20] * Joins: hober (ted@206.212.254.2)
- # [07:20] * Quits: hober (ted@206.212.254.2) (Client exited)
- # [07:30] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
- # [07:38] * Joins: hober (ted@206.212.254.2)
- # [08:03] * Joins: billyjackass (MikeSmith@mcclure.w3.org)
- # [08:08] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
- # [08:14] * billyjackass is now known as MikeSmith
- # [08:15] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
- # [08:15] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [08:22] * Joins: heycam (cam@203.217.95.190)
- # [10:26] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
- # [10:42] * Joins: Lachy (Lachlan@213.236.208.22)
- # [11:05] * Quits: harry (kcome@58.213.218.123) (Client exited)
- # [11:35] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: sex break)
- # [12:08] * Joins: arve (arve@213.236.208.22)
- # [12:09] * Joins: marcos (marcos@87.196.199.101)
- # [12:20] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [12:21] * Parts: gorm (gormer@213.236.208.22)
- # [12:24] * Joins: gorm (gormer@213.236.208.22)
- # [12:34] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: sex break)
- # [13:11] * Joins: tlr (tlr@128.30.52.30)
- # [13:35] * Quits: heycam (cam@203.217.95.190) (Ping timeout)
- # [13:37] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
- # [13:41] * Joins: heycam (cam@210.84.37.7)
- # [13:55] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
- # [13:55] * Joins: tlr (tlr@128.30.52.30)
- # [14:05] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
- # [14:26] * Joins: ArtB (ce846302@128.30.52.43)
- # [14:58] * Joins: aroben (aroben@71.58.119.193)
- # [15:01] * Joins: harry (kcome@222.94.59.107)
- # [15:21] * Joins: aroben_ (aroben@71.58.119.193)
- # [15:23] * Quits: aroben (aroben@71.58.119.193) (Ping timeout)
- # [15:25] * Joins: tlr (tlr@128.30.52.30)
- # [15:37] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [15:44] * Parts: gorm (gormer@213.236.208.22)
- # [16:11] <ArtB> marcos, yt?
- # [16:12] * Quits: marcos (marcos@87.196.199.101) (Quit: marcos)
- # [16:13] * Joins: marcos (marcos@87.196.199.101)
- # [16:14] * marcos IRC client went all screwy. If you sent me a message and I hadn't responded, please send it again :(
- # [16:15] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
- # [16:15] * Joins: tlr (tlr@128.30.52.30)
- # [16:15] <ArtB> marcos, yt?
- # [16:15] <marcos> yeah
- # [16:16] <ArtB> Regarding http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0340.html - which requirement is driving this?
- # [16:16] <marcos> Um, one that I should probably add to the requirements doc. Without it, widgets don't quite work I think.
- # [16:17] <ArtB> What is the missing requirement?
- # [16:19] <marcos> one sec... writing it...
- # [16:19] <marcos> In the case that the packaging format does not natively label resources with a MIME Type, a conforming specification MUST either specify or recommend a means of deriving the MIME type of resources.
- # [16:20] <ArtB> well, what's the use case
- # [16:20] * ArtB appologizes for having missed it ...
- # [16:21] <marcos> the use case is basically any appropriate processing of resources by the widget engine. It must known, for instance, to treat a .html file as text/html (and not as application/xhtml+xml, for instance)
- # [16:21] <ArtB> IOW, how do existing widget systems solve this problem?
- # [16:21] <marcos> sniffing and file extensions, I think, But I need to do some testing to prove that.
- # [16:22] <ArtB> I'm wondering if this is needed for v1
- # [16:22] <ArtB> Apparently you think yes
- # [16:22] <marcos> Without it, it leaves a massive gap. I think it is important and not a big deal to specify.
- # [16:23] <ArtB> "massive"?
- # [16:23] <marcos> well, massive is relative :)
- # [16:24] <tlr> "massive", as in, it's unspecified how a particular file within a widget package is interpreted
- # [16:24] <tlr> text/plain? ;-)
- # [16:25] <marcos> as tlr said. Artb, does that make sense?
- # [16:25] <ArtB> how do you know your done i.e. specified *every* possible file type?
- # [16:25] <marcos> Because there are only like 10 types that are commonly used on the web.
- # [16:26] <marcos> (or by widget user agents)
- # [16:26] <marcos> And that hasn't really changed in the last 10 years (apart from IE adding better support for PNG)
- # [16:27] <ArtB> does this mean we then need to specify a file type's "interpretation", tlr?
- # [16:27] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
- # [16:27] <tlr> http://www.iana.org/assignments/media-types/
- # [16:28] <tlr> ... is the registry that binds media types to specs
- # [16:28] <tlr> in client software, you'd traditionally use the mailcap file
- # [16:28] <tlr> RFC 1524
- # [16:28] <tlr> but that's a bit ancient
- # [16:29] <ArtB> I'm trying to understand what Interop we are trying to solve by documenting the top 10 file types
- # [16:29] <marcos> Artb, see http://www.leviathansecurity.com/pdf/Flirting%20with%20MIME%20Types.pdf
- # [16:29] * tlr wonders where the "document the top 10 file types" notion comes from
- # [16:29] <tlr> we need a mechanism that lets the widget engine determine the media type of a resource in the widget
- # [16:30] <ArtB> and that mechanism isn't alreday specified?
- # [16:30] <anne> nope
- # [16:34] * ArtB thinks this is a rat hole if we are going to LC in a week but will be optomistic ...
- # [16:34] * ArtB is now known as ArtB_
- # [16:36] * anne didn't know about LC
- # [16:36] * anne notes it needs to be defined one way or another
- # [16:36] <marcos> tlr, content type sniffing is the mechanism (as defined in HTML 5)
- # [16:38] <tlr> marcos, leaving my disagreement with content type sniffing aside for the moment, what I meant up there is "we need to pick one and specify what it is"
- # [16:38] <tlr> s/what/which/
- # [16:39] <marcos> I am specifying the file extension to MIME mapping, and content type sniffing as a fallback. It is up to the group if they want me to spec a MIME to file extension override (ala, Apache's addType)
- # [16:40] <marcos> File extension mapping seems like the easiest, and probably the most logical thing to do.
- # [16:40] <tlr> what's the source for the binding from extension to MIME type?
- # [16:42] <marcos> I'm sorry, what do you mean by source?
- # [16:43] <tlr> where do you get the data in that mapping from?
- # [16:44] <marcos> From the appropriate RFCs or specs
- # [16:44] <marcos> Artb, from that report. Opera 14
- # [16:44] <marcos> FireFox 8
- # [16:44] <marcos> Safari 7
- # [16:44] <marcos> argh... prematurely hit return
- # [16:45] <marcos> The numbers next to the browser names represent the number of types a browser is able to render
- # [16:46] <tlr> ... which might depend on system configuration
- # [16:46] <marcos> So, as you can see, the number is quite small.... if you exclude IE, which can render 696 types (LOL!)
- # [16:47] <tlr> I wonder how economical it is to introduce yet another content type determination method.
- # [16:47] <tlr> The clean way is to have a mapping from files to media types somewhere.
- # [16:47] <tlr> then we've got sniffing in HTML5
- # [16:47] <tlr> and now extensions?
- # [16:47] * tlr would rather not add more to the already existing confusion
- # [16:50] <marcos> If you can do mapping from file to media types, then you might as well bake that into the widget engine.
- # [16:53] <anne> that's the way it works today for widgets anyway
- # [16:53] <anne> although it probably works more like file:/// which is even less clean
- # [16:53] <marcos> my point exactly.
- # [16:58] <marcos> Artb, see pages 8-9 of the pdf link above for what each browser does WRT web pages. Note that Opera does: 1. Evaluate the advertized type from the Content-Type HTTP header.
- # [16:58] <marcos> 2. Evaluate the file extension of the resource.
- # [16:58] <marcos> 3. “Detect” the Content-Type by examining the resource.
- # [16:58] <marcos>
- # [16:59] <marcos> Firefox does not do any interpretation of the file extension, but instead just dives into sniffing for magic numbers
- # [17:00] <marcos> IE also does sniffing BEFORE it checks the file extension:
- # [17:00] <marcos> 1. Obtain the server-supplied MIME type (typically via the Content-Type HTTP header), if available
- # [17:00] <marcos> 2. Examine the actual contents associated with a downloaded URL
- # [17:00] <marcos> 3. Obtain the file name associated with the downloaded content (assumed to be derived from the associated
- # [17:00] <marcos> URL)
- # [17:00] <marcos> 4. Enumerate registry settings (file extension/MIME type associations or registered applications) impacted
- # [17:00] <marcos> during the download
- # [17:08] * Joins: Lachy (Lachlan@85.196.122.246)
- # [17:08] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
- # [17:08] * Joins: Lachy (Lachlan@85.196.122.246)
- # [17:18] <marcos> Anne, which MIME type should .js map to? application/javascript? or text/javascript? or something else?
- # [17:22] <anne> mwaha
- # [17:22] <anne> have fun
- # [17:22] <marcos> hehe
- # [17:28] * Quits: gsnedders (gsnedders@217.44.35.181) (Quit: Killin' teh intarwebs)
- # [17:29] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
- # [17:34] * Joins: gsnedders (gsnedders@217.44.35.181)
- # [17:57] * ArtB_ is now known as ArtB
- # [18:06] <ArtB> marcos, thanks for this additional information
- # [18:08] <marcos> np. As I have only skimmed through that report, I was actually wrong about the number of types a browser is able to render. The information given in the report is that a browser will render HTML for a certain number of MIME types given.
- # [18:08] <marcos> sorry if I mislead anyone
- # [18:13] <ArtB> btw, Marcos, I don't think the requirement you created above [albeit "on the fly" perhaps] captures the real intent for this mechanism
- # [18:18] * Parts: maxf (maxf@84.202.168.250)
- # [18:43] * tlr is now known as tlr-bbl
- # [18:50] * Quits: harry (kcome@222.94.59.107) (Ping timeout)
- # [19:19] * Joins: arve (arve@80.202.65.163)
- # [20:02] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
- # [20:40] * Joins: Lachy (Lachlan@85.196.122.246)
- # [21:21] * Joins: aroben__ (aroben@71.58.119.193)
- # [21:23] * Quits: aroben_ (aroben@71.58.119.193) (Ping timeout)
- # [21:24] * Joins: aroben_ (aroben@71.58.119.193)
- # [21:26] * Quits: aroben__ (aroben@71.58.119.193) (Ping timeout)
- # [21:32] <marcos> Artb, I'm adding the requirement to the Req doc. What is missing in your opinion?
- # [22:26] * Quits: ArtB (ce846302@128.30.52.43) (Quit: CGI:IRC)
- # [22:28] * Quits: tlr-bbl (tlr@128.30.52.30) (Quit: tlr-bbl)
- # [22:46] * Quits: heycam (cam@210.84.37.7) (Quit: bye)
- # [23:13] * Joins: heycam (cam@130.194.72.84)
- # [23:30] * Joins: arve_ (arve@80.202.65.163)
- # [23:33] * Quits: arve (arve@80.202.65.163) (Ping timeout)
- # Session Close: Thu Dec 04 00:00:00 2008
The end :)