headers
Edward Gerhold | 2 Mar 16:40
Gravatar

Improvement of the Application Cache

Hello,

i would like to suggest an improvement for the Offline Web applications.

Problem:
I´ve found out, that i can not Cache my Joomla! Content Management System.
Of course i´ve read and heard about, that the application cache is for
static pages.
But with a little change to the spec and the implementations, it would be
possible to cache
more than static pages.

I would like to cache my Joomla! system. To put the scripts, css and images
into the cache.
I would like to add the appcache manifest to the index.php file of the
Joomla Template.
What happens is, that the index.php is cached once and not updated again. I
can not view
new articles. The problem is, that i can neither update the Master File, nor
whitelist it.

And this is, what my request or suggestion is about. I would like to
whitelist the Master
file, where the appcache manifest is installed in. Or i would like to update
this file, or any
file else, i would like to update, on demand.

If there is any possibility, to do that already, please tell me. But i think
that is not the case.
(Continue reading)

Permalink | Reply |
headers
Michael Nordman | 3 Mar 22:50
Picon
Favicon

Re: Improvement of the Application Cache

Sounds like there are at least two feature requests here...

1) Some way of not adding the 'master' entry to the cache. This is a common
feature request, there's another thread about it specificially titled
"Application Cache for on-line sites".

2) The ability to add(), remove(), and enumerate() individual urls in the
appcache. Long ago, there were interfaces on the appcache drawing board to
allow that. They got removed for a variety of reasons including "to start
simpler". A couple of years later, it may make sense to revisit these kind
of features, although there is another repository also capable of storing
ad-hoc collection of resources now (FileSystem), so i'm not sure this
feature really needs to be in the appcache.

@Hixie... any idea when the appcache feature set will be up for a growth
spurt? I think there's an appetite for another round of features in the
offline app developers that i communicate with. There's been some recent
interest here in pursuing a means of programatically producing a response
instead of just returning static content.

On Wed, Mar 2, 2011 at 7:40 AM, Edward Gerhold <
edward.gerhold@...> wrote:

> Hello,
>
> i would like to suggest an improvement for the Offline Web applications.
>
> Problem:
> I´ve found out, that i can not Cache my Joomla! Content Management System.
> Of course i´ve read and heard about, that the application cache is for
(Continue reading)

Permalink | Reply |
headers
Joseph Pecoraro | 4 Mar 04:07
Picon
Favicon

Re: Improvement of the Application Cache

Sounds related to "Programmable HTTP Caching and Serving" (formerly titled DataCache API):
http://dev.w3.org/2006/webapi/DataCache/

  [[[ This document defines APIs for off-line serving of requests to
      HTTP resources using static and dynamic responses. It extends
      the function of application caches defined in HTML5. ]]]

- Joe

On Mar 3, 2011, at 1:50 PM, Michael Nordman wrote:

> Sounds like there are at least two feature requests here...
> 
> 1) Some way of not adding the 'master' entry to the cache. This is a common
> feature request, there's another thread about it specificially titled
> "Application Cache for on-line sites".
> 
> 2) The ability to add(), remove(), and enumerate() individual urls in the
> appcache. Long ago, there were interfaces on the appcache drawing board to
> allow that. They got removed for a variety of reasons including "to start
> simpler". A couple of years later, it may make sense to revisit these kind
> of features, although there is another repository also capable of storing
> ad-hoc collection of resources now (FileSystem), so i'm not sure this
> feature really needs to be in the appcache.
> 
> @Hixie... any idea when the appcache feature set will be up for a growth
> spurt? I think there's an appetite for another round of features in the
> offline app developers that i communicate with. There's been some recent
> interest here in pursuing a means of programatically producing a response
> instead of just returning static content.
(Continue reading)

Permalink | Reply |
headers
Michael Nordman | 4 Mar 20:59
Picon
Favicon

Re: Improvement of the Application Cache

Yes, it does, in particular the add(), remove(), and enumerate() parts. That
spec is in the act of being dropped by the webapps working group. I think if
we want to see features along those lines, we should see them in the context
of the HTML5 AppCache.

On Thu, Mar 3, 2011 at 7:07 PM, Joseph Pecoraro <pecoraro@...> wrote:

> Sounds related to "Programmable HTTP Caching and Serving" (formerly titled
> DataCache API):
> http://dev.w3.org/2006/webapi/DataCache/
>
>   [[[ This document defines APIs for off-line serving of requests to
>       HTTP resources using static and dynamic responses. It extends
>       the function of application caches defined in HTML5. ]]]
>
> - Joe
>
>
> On Mar 3, 2011, at 1:50 PM, Michael Nordman wrote:
>
> Sounds like there are at least two feature requests here...
>
> 1) Some way of not adding the 'master' entry to the cache. This is a common
> feature request, there's another thread about it specificially titled
> "Application Cache for on-line sites".
>
> 2) The ability to add(), remove(), and enumerate() individual urls in the
> appcache. Long ago, there were interfaces on the appcache drawing board to
> allow that. They got removed for a variety of reasons including "to start
> simpler". A couple of years later, it may make sense to revisit these kind
(Continue reading)

Permalink | Reply |
headers
Edward Gerhold | 6 Mar 21:16
Gravatar

Re: Improvement of the Application Cache

2011/3/3 Michael Nordman <michaeln@...>

> Sounds like there are at least two feature requests here...
>
> 1) Some way of not adding the 'master' entry to the cache. This is a common
> feature request, there's another thread about it specificially titled
> "Application Cache for on-line sites".
>

You got it right and i find it good, that the people have this topic already
discussed. Had expected that, but i´m glad, that someone tells me, that.
Some way of "not" adding the master file to the cache. Yes, or have the
master entry added, but letting it be threatened as an updateable file. I
would need to either update the file on demand, or whitelist and get it over
the network.
That would make add(), remove() and enumerate() neccessary for me. Not
adding it would be a possibility to pass that static
index page, too.

> 2) The ability to add(), remove(), and enumerate() individual urls in the
> appcache. Long ago, there were interfaces on the appcache drawing board to
> allow that. They got removed for a variety of reasons including "to start
> simpler". A couple of years later, it may make sense to revisit these kind
> of features, although there is another repository also capable of storing
> ad-hoc collection of resources now (FileSystem), so i'm not sure this
> feature really needs to be in the appcache.
>

Wouldn´t it be easier for the programmers, to have both, static and dynamic
pages together in one application cache? It is a
(Continue reading)

Permalink | Reply |
headers
Edward Gerhold | 6 Mar 22:05
Gravatar

Re: Improvement of the Application Cache

2011/3/3 Michael Nordman <michaeln@...>

> Sounds like there are at least two feature requests here...
>
> 1) Some way of not adding the 'master' entry to the cache. This is a common
> feature request, there's another thread about it specificially titled
> "Application Cache for on-line sites".
>

I got an idea for the keyword. To make it easier for Ian to formulate that.

Adding the Master File not to the CACHE.
Write
CACHE MANIFEST NOMASTER
on the first line of the manifest.

or
If you enter the master filename in the whitelist section, it is simply
CACHE MANIFEST
NETWORK:
/index.php

If the master file is cached, but needs to be updated.
applicationCache.update(0); or applicationCache.updateMaster();

If you want to look for entries in the cache. Maybe you want to look for,
wheter you need update the cache, because you got a newer version for the
cache, or not, because the file is not in the cache.

applicationCache.entries[]
(Continue reading)

Permalink | Reply |
headers
Edward Gerhold | 6 Mar 23:38
Gravatar

Re: Improvement of the Application Cache

I went already to bed. But i kept thinking about it. I would like to correct
myself a little, keep the idea alive and state it a little bit more clearly.

I think the functions where defined to loose or bound wrong to the
applicationCache object.
There should be the applicationCache.cache object which contains all the
entries (in my last mail .entries)
and the function should be bound to this object.

applicationCache.cache.get()
applicationCache.cache.add() - i think add should insert on existing urls or
index numbers
applicationCache.cache.set() - set should overwrite on existing urls or
index numbers
applicationCache.cache.update()
applicationCache.cache.remove()

I don´t know which events they fire, but names like the functions have look
good for me, and the event
data should have the data or the index numbers or urls. But every function
should fire an event.

The get and add methods should make it possible to add _data_ per parameter,
that i can _cache
on-the-fly generated content_ which is calculated by my application (i
wouldn´t need to write it down
maybe with the file api or save it otherwhere in the storage to include it
later in a space preserved for in the app-page).

The methods should accepts urls and index numbers.
(Continue reading)

Permalink | Reply |
headers
Edward Gerhold | 7 Mar 00:40
Gravatar

Re: Improvement of the Application Cache

Oh, i am so stupid. Ok, i correct myself once again and for the last time.
After this, i go to bed, can sleep, and will
continue with reading the original text again and think about that and how
to put that together, before i write any
mail again.

First of all, i noticed, i forgot the [i] after the .cache, as i listed the
datatypes. Then i laughed internally about myself
coz i´ve gotten it all wrong. After i bound the functions to
applicationCache, i wanted to return the cache entries
as an object to a variable and operate on the entries in the container After
sending the last mail i thought i could
move applicationCache.cache back to applicationCache. I speak here about my
last message.
applicationCache is of course the container of the entries[], i believe, for
being sure i have to read the original again
and that is what i will, afterwards.

The functions of course have to be bound to the container of the entries,
but that will be applicationCache, of course.
This is what i assign to a variable and then i use the functions in the
container for the entries (word from the spec
should be used here).

I am sorry, that i´ve put it out and moved it to the right and sent it to
you.

I am not shure, that filesystem and appcache would conflict. Thinking about
it twice i couldn´t even use that
together, both implementations have not much together. If i get the master
(Continue reading)

Permalink | Reply |

Gmane