Enumerating a ResourceStore

[magixman]

I am integrating a CMS-like system with Gears. Things are going very
well and I am quite impressed so far with the design and usability of
the API. One small issue I am running into is that I have images in
my content which I add to the ResourceStore as they come down from the
server. I need a way to 'garbage collect' images that are no longer
referenced in the content.

On the server I run a background task periodically which examines the
content, makes a list and kills stuff not on the list. A high water
mark makes this safe and easy to do and much more efficient than
maintaining a complex cross reference.

I would like to do the same thing on the client but I can't seem to
find a way to do this other than to add a database record each time I
capture a URL so I know what has been captured. So my question is
whether there is or will eventually be a way to enumerate the
ResourceStore?

[Chris Prince]

Hi magixman,

We don't currently have plans to add resource store enumeration. I'd
predict that most efforts related to LocalServer will probably be
aimed at implementing HTML5 offline web application support.

Using the database to record status should certainly work.

Another idea: is there any way you could create a separate manifest
for the content you want to track? ManagedResourceStore already does
most of the database tracking and resource purging that you describe.
So you may be able to save a lot of work that way.

--Chris

[magixman]

I can certainly work around this issue so no big worries. I would
still point out for the record that a ResourceStore is essentially a
collection and that you would be hard pressed to find an API for a
collection that has no way to enumerate or iterate through the items
in that collection. For example HTML 5 offline support has the
ApplicationCache API which does have a method to enumerate in the form
of the item method which accepts an index and returns the dynamically
added items.

Is the idea about the convergence with HTML 5 to have the Gears API
mapped to HTML 5 features where there is overlap, to have Gears
support HTML 5 in browsers that don't support it or to propose that
HTML 5 adopt some of the Gears features?

Aaron has an interesting blog post about the future of HTML 5 and
Gears

http://gearsblog.blogspot.com/2008/04/gears-and-standards.html

Still I was not entirely clear about how they ultimately might
converge. Knowing a bit more about the path would help us in planning
and structuring for the future.

On Jul 19, 3:40 pm, "Chris Prince" <cpri...@google.com> wrote:
> Hi magixman,
>
> We don't currently have plans to add resource store enumeration. I'd
> predict that most efforts related to LocalServer will probably be
> aimed at implementing HTML5 offline web application support.
>
> Using the database to record status should certainly work.
>
> Another idea: is there any way you could create a separate manifest
> for the content you want to track? ManagedResourceStore already does
> most of the database tracking and resource purging that you describe.
> So you may be able to save a lot of work that way.
>
> --Chris
>

[Chris Prince]

> Is the idea about the convergence with HTML 5 to have the Gears API
> mapped to HTML 5 features where there is overlap, to have Gears
> support HTML 5 in browsers that don't support it or to propose that
> HTML 5 adopt some of the Gears features?

> [snip]

> I was not entirely clear about how they ultimately might converge.
> Knowing a bit more about the path would help us in planning
> and structuring for the future.

We want to be careful not to break existing applications. So that
means two APIs would be exposed: Gears V1 and HTML5.