Alex Limi's resource packages
I have carefully read Alexander Limi's proposal for resource packages. Good idea with potential very tangible results (that's something that ol'timers like me have seen many times proposed in other flavors during the last eighteen years) but with a major side issue : individual resources are not reachable by a single URL any more and I think it just breaks the Web as we know it. The wrong key here is that if you're not inside an HTML document holding the new proposed link element, you just can't reach the individual resources only through a URL. I don't want individual resources on the Web to be hidden inside jars. There is also a warning bell ringing in my head about password-protected zips holding resource packages and I don't want to see that happen ; maybe I'm just pessimistic here but I tend to follow my intuition and listen to this kind of warning bells...
So I think a better idea would be a new URL scheme like the following one (don't focus on the syntax since I'm only thinking at loud here, try to understand the idea behind please...)
packaged:styles/main.css|http://www.example.com/package.zip
Then you don't need a link element to declare the package and each resource remains individually reachable even outside of an HTML document. Furthermore, the browser can cache the downloaded resource after first access so you still need only one access. In other terms, the good sides of Alexander's proposal minus its bad side effects, IMHO. I understand this is bad for legacy browsers since they won't reach the resources if they have a new form of URL they don't groke ; maybe we can find a fallback mechanism that resolves that issue... But I really think that we should preserve access to individual objects inside zips even outside of an HTML document.
Comments
regarding legacy browser, how about an url like this:
styles/main.css##http://www.example.com/package.zip
"I understand this is bad for legacy browsers since they won't reach the resources if they have a new form of URL they don't groke"
... at which point you can just use the jar protocol, which exists today. And of course it would also still exist side-by-side with Limi's proposal.
The individual resources are still available at their respective URL's under Alex's idea.
As far as I can see, the <link> element is just a hint saying "resources referenced in this page might also be available from here".
I don't think using a new URI scheme is workable from a backwards compat angle or from a "don't hide things" view.
Pete's idea seems like a nice substitute for a <link>, although ## would need to be tested for compatibility.
Hi !
Sorry for being a total dummy, but why can't we have the following :
http://www.example.com/package.zip#...
It's the same than for anchors in HTML, it just points to something inside the page/package.
Could you tell me ? (since I think this has already been studied and rejected)
What "Fowl" said.
Resources will continue to be reachable at their normal address (ie. outside the archive), which means that browsers that do not support this new standard will just get the resources as they always have.
The idea I got from Alexander's proposal is that static resources -- images, style sheets, etc. -- would be in the package for download if the browser supports the new <link> element, probably mimicking the site's directory structure within the zip to avoid name collisions.
Since (again, by my understanding) all images used by CSS would presumably be in there already your idea is redundant with his and doesn't solve any problems. (Password-protected zip files would be just as useless under your proposal as his.)
I suppose that in theory you could break the web by pointing directly to the package, like HTML e-mails do with cid: references, but that seems like it would be more work than just doing them like normal. But the solution to that is to support it before any eeeeevil browsers do, so they have nothing to gain from trying to break things.