On Friday, May 10, 2013 at 2:23 AM, Jonas Sicking wrote:
On Thu, May 9, 2013 at 9:36 AM, Marcos Caceres w...@marcosc.com
(mailto:w...@marcosc.com) wrote:
On Wednesday, May 8, 2013 at 2:05 PM, Robin Berjon wrote:
How do you figure out media types? Is it just sniffing, or do you have
On 10/05/2013 03:23 , Jonas Sicking wrote:
On Thu, May 9, 2013 at 9:36 AM, Marcos Caceres w...@marcosc.com wrote:
On Wednesday, May 8, 2013 at 2:05 PM, Robin Berjon wrote:
How do you figure out media types? Is it just sniffing, or do you have
some sort of file extensions mapping as well?
Would it be possible (not suggesting this would be the common story) to
reference a zipped asset directly via the full url, sans a link tag?
Hi Brian,
On 10/05/2013 15:32 , Brian Kardell wrote:
Would it be possible (not suggesting this would be the common story) to
reference a zipped asset directly via the full url, sans a link tag?
Can you hash out a little bit more how this would work? I'm assuming you
mean something like:
Can you hash out a little bit more how this would work? I'm assuming you
mean something like:
img src='/bundle.zip/img/dahut.jpg'
Meh, sorta - but I was missing some context on the mitigation strategies -
thanks for filling me in offline.
Still, same kinda idea, could you add an attribute
I've been looking at some of these alternatives for my RO Bundle
specification, which is basically a ZIP file.
http://purl.org/wf4ever/ro-bundle/2013-05-10/#absolute-uris
I have not yet decided which of these schemes would be used in my
approach, which is why the above contains these
On 10/05/2013 17:13 , Brian Kardell wrote:
Still, same kinda idea, could you add an attribute that allowed for it
to specify that it is available in a bundle? I'm not suggesting that
this is fully thought out, or even necessarily useful, just fleshing out
the original question in a potentially
This seems very related to how prefixes/terms are expanded to IRIs in
JSON-LD - see http://www.w3.org/TR/json-ld/#iris
The JSON-LD approach is more like registering new local protocols,
as they look like URIs.
If we tried that out, then:
link rel=bundle href=/bundle.zip anchor=b2 /
would mean
I'm not sure it matters, I suppose it depends on:
a) where the link tag will be allowed to live
You can use link anywhere. It might not be valid, but who cares about
validity :) It works.
Some people :) why does it have to be invalid when it works. Lame, no?
b) the effects created by
On May 9, 2013 9:03 AM, Robin Berjon ro...@w3.org wrote:
On 07/05/2013 20:57 , Jonas Sicking wrote:
Will this let us support reading things from blob: URLs where the Blob
contains a zip file? I.e. what Gecko would support as
jar:blob:abc-123!/img/foo.jpg.
Yeah:
var blob = new
On 07/05/2013 22:35 , Bjoern Hoehrmann wrote:
There have been many proposals over the years that would allow for some-
thing like this, http://www.w3.org/TR/DataCache/ for instance, allows to
intercept certain requests to aid in supporting offline applications,
and `registerProtocolHandler`
On 07/05/2013 20:57 , Jonas Sicking wrote:
Will this let us support reading things from blob: URLs where the Blob
contains a zip file? I.e. what Gecko would support as
jar:blob:abc-123!/img/foo.jpg.
Yeah:
var blob = new Blob(zipContent, { type: application/bundle })
, burl =
On 08/05/2013 01:39 , Glenn Maynard wrote:
On Tue, May 7, 2013 at 9:29 AM, Robin Berjon ro...@w3.org
mailto:ro...@w3.org wrote:
Have you looked at just reusing JAR for this (given that you support
it in some form already)? I wonder how well it works. Off the top of
my head I see at
On 07/05/2013 22:31 , David Sheets wrote:
On Tue, May 7, 2013 at 3:29 PM, Robin Berjon ro...@w3.org wrote:
WDYT?
This is really cool!
Glad you like it :)
Most servers already contain support for this in the form of index files.
If you do
link rel=bundle href=bundle.wrap/ /
and set
On Wednesday, May 8, 2013 at 2:05 PM, Robin Berjon wrote:
How do you figure out media types? Is it just sniffing, or do you have
some sort of file extensions mapping as well?
Sniffing would probably sufficient. The types on the web are pretty stable.
--
Marcos Caceres
On Thu, May 9, 2013 at 9:36 AM, Marcos Caceres w...@marcosc.com wrote:
On Wednesday, May 8, 2013 at 2:05 PM, Robin Berjon wrote:
How do you figure out media types? Is it just sniffing, or do you have
some sort of file extensions mapping as well?
Sniffing would probably sufficient. The types
On Tue, May 7, 2013 at 7:29 AM, Robin Berjon ro...@w3.org wrote:
This isn't very different from JAR but it does have the property of more
easily enabling a transition. To give an example, say that the page at
http://berjon.com/ contains:
link rel=bundle href=bundle.wrap
and
img
* Anne van Kesteren wrote:
On Tue, May 7, 2013 at 7:29 AM, Robin Berjon ro...@w3.org wrote:
This isn't very different from JAR but it does have the property of more
easily enabling a transition. To give an example, say that the page at
http://berjon.com/ contains:
link rel=bundle
On Tue, May 7, 2013 at 11:34 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Robin seems to address that in the parts of his mail you didn't quote.
My bad :-(
Have to say it does seem quite elegant. And has great fallback (if
implemented on the server).
--
http://annevankesteren.nl/
On Tue, May 7, 2013 at 7:29 AM, Robin Berjon ro...@w3.org wrote:
On 06/05/2013 20:42 , Jonas Sicking wrote:
The only things that implementations can do that JS can't is:
* Implement new protocols. I definitely agree that we should specify a
jar: or archive: protocol, but that's orthogonal to
* Robin Berjon wrote:
I wonder if we couldn't have a mechanism that would not require a
separate URI scheme. Just throwing this against the wall, might be daft:
We add a new link relationship: bundle (archive is taken, bikeshed
later). The href points to the archive, and there can be as many as
On Tue, May 7, 2013 at 9:29 AM, Robin Berjon ro...@w3.org wrote:
Have you looked at just reusing JAR for this (given that you support it in
some form already)? I wonder how well it works. Off the top of my head I
see at least two issues:
JARs are just ZIPs with Java metadata. We don't need
22 matches
Mail list logo
