As far as I understand from the specs the ’no-store’ header should should
prevent a master entry from being cached. Is it correct ?
If the resource was labeled with the no-store cache directive
Skip this resource. It is dropped from the cache.
Mihai.
lacking an actual spec, is getting considerable traction as
the path to follow for fixing appcache.
It would be useful to get a sense of whether people think we should do
something else.
cheers
Chaals
Send from my Samsung Galaxy Note II
El 28/11/2013 07:21, eli elib...@gmail.com escribió
The only problem I see now with that approach is that a browser that
supports
both webm and mp4 videos would download both videos. It seems to me there
should be a way for the browser to determine duplicate content in the
manifest
file in the same way that it determines which video file to
The web is server + client sides. Trying to fix issues you have with
client technologies only (appcache, JavaScript, ...) will always be a bad
choice.
I disagree, Javascript and web browsers are becoming powerful enough
to delegate servers to their barebones, just offering storage or
Json manifest seems a nice solution to me :-)
Send from my Samsung Galaxy Note II
El 28/11/2013 07:21, eli elib...@gmail.com escribió:
The web is server + client sides. Trying to fix issues you have with
client technologies only (appcache, JavaScript, ...) will always be a
bad
choice.
The web is server + client sides. Trying to fix issues you have with
client technologies only (appcache, JavaScript, ...) will always be a bad
choice.
I disagree, Javascript and web browsers are becoming powerful enough
to delegate servers to their barebones, just offering storage or
databases
The web is server + client sides. Trying to fix issues you have with
client technologies only (appcache, JavaScript, ...) will always be a bad
choice.
I disagree, Javascript and web browsers are becoming powerful enough
to delegate servers to their barebones, just offering storage or
To be available offline, the device has to hit a server first, then the
appcache magic happens.
Obviously.
No reason the server couldn't prepare / select what to send to the device:
iOS won't support WebM anytime soon, there is no reason to constantly ask iOS
device the same info again
Your manifest file should be dynamically generated by your server, based
on what you know about the user's browser.
Now you have one single manifest file which is easier for updates, +
server-side language comments so documentation is easy.
The web is server + client sides. Trying to fix issues
Why not attempt to give the browser-side manifest functionality
the ability to feature test for file support instead? Then the browsers
can be the trusted source instead of everyone having to create new divergent
browser file support inference hacks.
This seems to me that this is some kind of
Le 25 nov. 2013 à 17:27, James Greene james.m.gre...@gmail.com a écrit :
Your manifest file should be dynamically generated by your server, based on
what you know about the user's browser.
Now you have one single manifest file which is easier for updates, +
server-side language
This seems to me that this is some kind of add scripting habilities to
the AppCache manifest, while we already have Javascript, and allowing
it to do that will lead us to something fairly similar (in fact, a
sub-set) of what ServiceWorkers can do. Why duplicate efforts then?
Manifest files
1. I'm not advocating for full scriptability, just basic support detection,
e.g.:
`if accepts(audio/ogg) ...`
Some kind of basic scriptability like the one on CSS, isn't it? Ok, it's good.
The main problem I'd see there is if the browser also needs to know what
plugins
(or
when providing feedback.
There has been a lot of debating about fixing appcache. Last year
mozilla got a few people together mostly with the goal of
understanding what the actual problems were. The notes from that
meeting are available at [1].
Those discussions, and a few followup ones, has
!
Apologies in advance for a long email. This is a complex subject and I
wanted to present a coherent proposal. Please don't be shy about
starting separate threads when providing feedback.
There has been a lot of debating about fixing appcache. Last year
mozilla got a few people together mostly
Come on!? Deal with flash players seems to me like a regression.
On Wed, May 1, 2013 at 1:14 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Apr 3, 2013 at 5:50 AM, Robin Berjon ro...@w3.org wrote:
On 29/03/2013 21:08 , Jonas Sicking wrote:
* Cache both files (poor bandwidth)
* We
I think there are some good use cases for not-quite-offline as well. Sort
of a combination of your twitter and wikipedia use cases:
Community-content site: Logged-out users have content cached aggressively
offline - meaning every page visited should be cached until told otherwise.
Intermediate
.orgmailto:public-webapps@w3.org
Subject: Re: Collecting real world use cases (Was: Fixing appcache: a proposal
to get us started)
I think there are some good use cases for not-quite-offline as well. Sort of a
combination of your twitter and wikipedia use cases:
Community-content site: Logged-out
On Apr 18, 2013 6:19 PM, Paul Bakaus pbak...@zynga.com wrote:
Hi Jonas,
Thanks for this I feel this is heading somewhere, finally! I still need
to work on submitting my full feedback, but I'd like to mention this: Why
did nobody so far in this thread include real world use cases?
For a
On Mon, Apr 1, 2013 at 4:03 AM, Glenn Jones
glennjones...@googlemail.com wrote:
I think this outline for improving AppCache is a really good start, but I
can see one major problem with it. As you point out AppCache was initially
designed for building simple single page web apps.
The appcache
On Wed, Apr 3, 2013 at 5:50 AM, Robin Berjon ro...@w3.org wrote:
On 29/03/2013 21:08 , Jonas Sicking wrote:
* Cache both files (poor bandwidth)
* We could enable some way of flagging which context different URLs
are expected to be used in. That way the UA can send the normal
content
On 01/05/2013, at 2:20 PM, Jonas Sicking jo...@sicking.cc wrote:
The current AppCache spec suffers from this too, but only once users
go offline. I.e. I can use FALLBACK to take over
http://users.example.edu/~alice/ using a resource from from
http://users.example.edu/~bob/newalice.html
. This is a complex subject and I
wanted to present a coherent proposal. Please don't be shy about
starting separate threads when providing feedback.
There has been a lot of debating about fixing appcache. Last year
mozilla got a few people together mostly with the goal of
understanding what the actual problems
On 2013-03-27 01:20, Jonas Sicking wrote:
On Tue, Mar 26, 2013 at 1:48 AM, James Graham jgra...@opera.com wrote:
On 03/26/2013 08:02 AM, Jonas Sicking wrote:
Another feature that we are proposing is to drop the current
manifest format and instead use a JSON based one. The most simple
reason
threads when providing feedback.
There has been a lot of debating about fixing appcache. Last year
mozilla got a few people together mostly with the goal of
understanding what the actual problems were. The notes from that
meeting are available at [1].
Those discussions, and a few followup ones, has
On 4/18/13 12:19 PM, ext Paul Bakaus wrote:
Do you have a list collected somewhere?
Hi Paul,
FYI, you might be able to scrape some UCs from the related workshop
papers http://www.w3.org/2011/web-apps-ws/Papers.
Virginie's paper includes a few (security-related) UCs
. This is a complex subject and I
wanted to present a coherent proposal. Please don't be shy about
starting separate threads when providing feedback.
There has been a lot of debating about fixing appcache. Last year
mozilla got a few people together mostly with the goal of
understanding what
On 24/03/2013, at 11:33 AM, Charles McCathie Nevile cha...@yandex-team.ru
wrote:
Hi,
we've been talking about appcache inside Yandex. Actually we're not at all
sure that appcache is what we really want, so much as an API to use the
normal cache better.
+1, I'm working on some proposals
Hi Jonas,
I don't get a good sense from this proposal (and NavigationController) about
what the scope of an application is. E.g., if both
http://example.com/fooApp
and
http://example.com/barApp
say that they both grab the URL
http://example.com/app
who wins?
More to the point, what's
On Wed, 03 Apr 2013 14:50:53 +0200, Robin Berjon ro...@w3.org wrote:
On 29/03/2013 21:08 , Jonas Sicking wrote:
* Cache both files (poor bandwidth)
* We could enable some way of flagging which context different URLs
are expected to be used in. That way the UA can send the normal
content
On 04/04/2013 15:41 , Simon Pieters wrote:
On Wed, 03 Apr 2013 14:50:53 +0200, Robin Berjon ro...@w3.org wrote:
On 29/03/2013 21:08 , Jonas Sicking wrote:
* Cache both files (poor bandwidth)
* We could enable some way of flagging which context different URLs
are expected to be used in. That
Hi Chaals,
On 24/03/2013 01:33 , Charles McCathie Nevile wrote:
2. Bundles.
Sometimes we need to load several resources (js/css/json/...) before we
can actually show something to user. Like a dialog, or another complex
control. Or if it's a single page application before change page.
Again,
On 29/03/2013 21:08 , Jonas Sicking wrote:
* Cache both files (poor bandwidth)
* We could enable some way of flagging which context different URLs
are expected to be used in. That way the UA can send the normal
content negotiation headers for images vs media files. I'm not sure
that this is
On Tue, Mar 26, 2013 at 7:02 AM, Jonas Sicking jo...@sicking.cc wrote:
The details of the API in this worker is something we haven't looked
at yet. It's a very big task in and of itself. Fortunately, Alex
Russell and a few others have worked on a proposal for exactly this at
[2]. The intent is
I love the idea! It is the best solution listed so far.
On Wed, Apr 3, 2013 at 9:50 AM, Robin Berjon ro...@w3.org wrote:
On 29/03/2013 21:08 , Jonas Sicking wrote:
* Cache both files (poor bandwidth)
* We could enable some way of flagging which context different URLs
are expected to be used
I think this outline for improving AppCache is a really good start, but I
can see one major problem with it. As you point out AppCache was initially
designed for building simple single page web apps.
The appcache appears to be aimed at too simple applications. It works
fine if the website you
On Tue, Mar 26, 2013 at 7:40 PM, Alec Flett alecfl...@chromium.org wrote:
This is a tricky problem indeed.
The current appcache actually has the behavior that you're advocating,
but that's something that a lot of developers has complained about. In
fact, that's the second biggest complaint
On Tue, Mar 26, 2013 at 10:03 PM, Emerson Estrella
emerson.estre...@gmail.com wrote:
I'm writing a web application that uses the AppCache API for offline
browsing. But I'm also using the Audio API to play back-ground music and a
few audio effects.
For audio support in different browsers I'm
I'm writing a web application that uses the AppCache API for offline
browsing. But I'm also using the Audio API to play back-ground music and a
few audio effects.
For audio support in different browsers I'm delivering each sound/music in
two different file formats: OGG and MP3.
The problem is
Hi WebApps!
Apologies in advance for a long email. This is a complex subject and I
wanted to present a coherent proposal. Please don't be shy about
starting separate threads when providing feedback.
There has been a lot of debating about fixing appcache. Last year
mozilla got a few people
On 03/26/2013 08:02 AM, Jonas Sicking wrote:
Another feature that we are proposing is to drop the current
manifest format and instead use a JSON based one. The most simple
reason for this is that we noticed that the information we need to
express quickly became complex enough that using a
One feature I'd like to see is respect for compression headers. I've got an
app which results in a 30Mb app cache, but it's only 8Mb over the wire due
to GZIP compression. I'd much prefer the appcache to see that the content
was served compressed, cache it compressed, and serve it to the browser
On 26 March 2013 07:02, Jonas Sicking jo...@sicking.cc wrote:
{
expiration: 300,
cache: [index.html, index.js, index.css]
}
If the user navigates to index.html The following happens:
If the user is online and we haven't checked for update for the
appcache in the last 5 minutes (300
* Jonas Sicking wrote:
There has been a lot of debating about fixing appcache. Last year
mozilla got a few people together mostly with the goal of
understanding what the actual problems were. The notes from that
meeting are available at [1].
(I take it the fixing-appcache mailing list has since
On Tuesday, March 26, 2013 at 12:12 PM, Bjoern Hoehrmann wrote:
(I take it the fixing-appcache mailing list has since been closed in
http://www.w3.org/community/fixing-appcache/ favour of discussion here.)
Yes, see:
http://lists.w3.org/Archives/Public/public-fixing-appcache/2013Feb/0005.html
On Tue, Mar 26, 2013 at 3:21 AM, Jake Archibald jaffathec...@gmail.com wrote:
On 26 March 2013 07:02, Jonas Sicking jo...@sicking.cc wrote:
{
expiration: 300,
cache: [index.html, index.js, index.css]
}
If the user navigates to index.html The following happens:
If the user is online
On Tue, Mar 26, 2013 at 1:48 AM, James Graham jgra...@opera.com wrote:
On 03/26/2013 08:02 AM, Jonas Sicking wrote:
Another feature that we are proposing is to drop the current
manifest format and instead use a JSON based one. The most simple
reason for this is that we noticed that the
This is a lot to digest, but I know the developer community will greatly
appreciate the work that has gone into this—thank you.
On Tue, Mar 26, 2013 at 3:02 AM, Jonas Sicking jo...@sicking.cc wrote:
(snip)
First we need a way to get at AppCache objects:
No mention of installAppCache,
On Tue, Mar 26, 2013 at 6:28 PM, Rick Waldron waldron.r...@gmail.com wrote:
This is a lot to digest, but I know the developer community will greatly
appreciate the work that has gone into this—thank you.
Yeah, I hope this is possible to consume despite its length. I'll
create a shorter writeup
On Tue, Mar 26, 2013 at 9:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Mar 26, 2013 at 6:28 PM, Rick Waldron waldron.r...@gmail.com
wrote:
This is a lot to digest, but I know the developer community will greatly
appreciate the work that has gone into this—thank you.
Yeah, I hope
This is a tricky problem indeed.
The current appcache actually has the behavior that you're advocating,
but that's something that a lot of developers has complained about. In
fact, that's the second biggest complaint that I've heard only
trailing the confusing master entries behavior.
I
Sounds like you want 304?
Sendt fra en Samsung MobilCharles McCathie Nevile cha...@yandex-team.ru
skrev:Hi,
we've been talking about appcache inside Yandex. Actually we're not at all
sure that appcache is what we really want, so much as an API to use the
normal cache better. Right now we
Hi,
we've been talking about appcache inside Yandex. Actually we're not at all
sure that appcache is what we really want, so much as an API to use the
normal cache better. Right now we prefer to use local storage, since
appcache isn't actually helpful. Anyway, here are some use cases:
1.
53 matches
Mail list logo
