W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2011

[whatwg] Pain with the Headers in webkit/appcache.

From: Edward Gerhold <edward.gerhold@googlemail.com>
Date: Wed, 1 Jun 2011 21:32:20 +0200
Message-ID: <BANLkTimXbm8r+GaWArtm91Vra==eMEhOCA@mail.gmail.com>
Me again..

Won?t continue writing down every step. But my next look, i?ll be motivated
now, tells me one thing:

Create a _new header_ with the Interfaces, and work on the manifest
structure. This is what the rest of the files in webkit/appcache do with all
the data.
I shouldn?t write the functions into class Manifest. Simply work with the
existing Manifest and the Operations get the Lists and do something with.
How to read and write the Page data, that is written in the code in the
other Files. The class Manifest is bound to the manifest parser file.
I could call it manifest_manipulator or think again about it. But i think,
being better readable and fitting better in webkit, i shouldn?t write into
manifest_parser.

Is it easier to add a new file to such a branch or to patch an existing?
Looks it better to seperate the new functions from the manifest, even if
they belong, too?
Good, i?ll find out.

Uhm, and another workaround for the update function in a CMS is to let the
CMS generate the manifest again with new version number and the additional
or removed files.
Make sure to document, that people using your cached site, would sometimes
rather check chrome://appcache-internals and delete, than waiting for any
update to be sure,
to check out the latest. But that is only working around the statics of the
application cache.

Ok, i?m motivated again. Inform you in around 6 weeks, if you like to think
about the better cache, just do so. It?ll make the world look better. My aim
is to read some hours now,
that will be self-explanatory for me then.

Greeting

Edward Gerhold
Received on Wednesday, 1 June 2011 12:32:20 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC