- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 01 Sep 2009 08:42:47 -0400
- To: Mikko Rantalainen <mikko.rantalainen@peda.net>
- CC: www-style@w3.org
Mikko Rantalainen wrote: > I agree that "already supported by browsers" does not count that much > because although some browsers have native ZIP archive support (through > jar: URL scheme) they still would not support the resource-package > specification without changes. Yes, indeed. > Major issues with ZIP (listed in the article as well): > * no way to specify content-type (incl. charset) > * no resource specific expiry time Right. On the other hand, I believe every off-the-shelf archiving format other than multipart MIME types has the former problem, and every single one has the latter problem, right? For the image use case, I should note, the type thing is a non-issue: browsers don't use any part of the Content-Type header for images (MIME type is sniffed, and charset is not relevant). For CSS and script it's a problem, as the proposal notes; it's not clear whether it's enough of one to matter. In practice, authors almost never set the charset on such resources anyway, especially in the case of scripts. For CSS there's @charset. For all cases, there is the possibility of a bit of additional complexity in the form of a manifest file with metainformation... > The article also mentions that ZIP archives have the index at the end of > the file which I believe is correct. If you cannot access the end of the > file, you cannot extract any given file inside it. As a result, no > incremental downloads from inside the resource package. I believe the index is at the end of the file but the file separators are well defined. So you can extract all the files one by one as the zip streams in; you just don't know what they're called. This is in fact a problem; that's why the idea of a manifest file was floated. Of course if there's a better compression format more amenable to use here, that would be nice too. I'm not sure there's an obvious candidate. > The proposal still has really nice idea behind it and I'd suggest doing > it - just replace the ZIP packaging with compressed TAR archive. GZIP > compression would result in high performance decompression, BZIP2 > compression would result in smaller packages. Both formats would allow > incremental downloads. I'm not sure if TAR format allows including MIME > type or expiry time per file It doesn't. > - if not, then use some other format instead. Which one? Note that support for creating compressed tar archives on Windows is not so great last I checked. I think they can be opened without too much trouble, but creation is a different kettle of fish... Or have things changed recently on this front? -Boris
Received on Tuesday, 1 September 2009 12:43:34 UTC