Another perspective about the problem: what about doing so with
"SharedIndexedDB" in the same way of SharedWorkers? They allow to be
accessed using a name, so it would be useful also here...
If you need a better use case, I've been last saturday on the
FirefoxOS App Days here at Madrid and talking
Good point. You are right about the fact if you a server somewhere it's
fairly simple just to popula it, but if you don't have it I don't know what
would be a good solution. Maybe the problem is that I misconsidered the
posibility that databases can be removed at any time? IndexedDB is designed
jus
On Tue, Jan 15, 2013 at 3:57 PM, pira...@gmail.com wrote:
> Ideas? Doubts? Comments? :-)
>
The use case here is not compelling enough for this amount of complexity.
IndexedDB is not guaranteed to be persistent so you can't really have a
server-less webapp if you want reliability. Once you have s
It will need to address limiting quota.
How about ad firm collect data from multiple origins?
Since user agent can delete IndexedDB data anytime, duplicate copy of
IndexedDB data to be more persistant is not much meaningful.
I think it is too much complex in security and privacy issue, but very
I have keep thinking about this topic and found a good solution: implement
a CORS-like functionality.
This way, when an IndexedDB database is created for the first time (like
when browser ask to the user if s/he allow that the page store data on this
machine) the developer could define an optional
>
>
> Perhaps what we need (and I am ducking as I say this) is a meta tag for
> web pages, e.g.
>
> http://olddomain.com:80";>
>
> or
>
> http://olddomain.com:80";>
>
> ** **
>
> This could then be used by the browser to allow the user (always in
> control of such decisions) to gr
ebapps@w3.org
Subject: Re: [IndexedDB] How to recover data from IndexedDB if the origin
domain don't exist anymore?
Hacky, but nice trick (really, I like it :-) ). My question was more related
about looking for a solution available for non-techies users, or give a warning
about a (
In this situation, I will go with CouchDB.
If used with IndexedDB, I will send data back JSON data to blob storage
server like Google Cloud Storage or S3.
Hacky, but nice trick (really, I like it :-) ). My question was more
related about looking for a solution available for non-techies users, or
give a warning about a (valid?) corner-case on the specification.
(I'm going to add an issue on my project tracker to remind me to develop
your idea, it's r
As a practical matter, you could just make an entry in your /etc/hosts mapping
the domain to localhost and write a web page that dumps the indexeddb as json.
Serve that from your local web server and hit it with your browser.
On Jan 8, 2013, at 7:08 AM, pira...@gmail.com wrote:
> I have been
I have been looking on Internet and reading the spec but didn't be able to
get at answer.
Let's see the next situation: I've developed a webapp that use IndexedDB to
store personal data. It's pure client-side and server-less, being all the
content of the webapp just static files and served with st
11 matches
Mail list logo
