the transaction alive for a certain amount of time.
Joran Greef
Apps (native/web) need direct access to bare metal.
Browser vendors need to move away from the we do all the thinking and
designing and implementing top-down model of innovation.
Browser vendors need to provide minimal core OS APIs and get out of the way and
let open source grow around and do
On 17 Sep 2012, at 2:33 PM, Florian Bösch pya...@gmail.com wrote:
Security is a pretty serious concern if you're distributing apps without any
oversight to billions of users automatically upon a single link click.
You are conflating web apps (trusted, installed) with web pages (single link
Given the advance of HTML 5, and in the interest of developing web apps with
average functionality, would it now be possible to:
1. Drag files and folders into a web app?
2. Drag files and folders out of a web app?
3. Drag a spreadsheet out of a web app onto the icon of Excel in the dock and
Web applications need a way to communicate between two same domain
tabs without polling LocalStorage and without hitting the disk.
It would be useful to have an in-memory get/set/compare_and_set hash
table exposed to scripts running same domain tabs, that is discarded
by the browser when those
IndexedDB supports binary values as per the structured clone algorithm
as implemented in Chrome and Firefox.
IndexedDB needs to support binary keys (ArrayBuffer, TypedArrays).
Many popular KV stores accept binary keys (BDB, Tokyo, LevelDB). The
Chrome implementation of IDB is already serializing
It would be great if there was a way to use IndexedDB to get just a
slice of a record value, not the entire value.
For example, when storing many large binary values, there may be
useful meta or header info at the start or end of each value, which
could be retrieved directly.
It would be a waste
The problem is we're framing the discussion in terms of installing web apps.
We're answering the wrong question.
The real question is whether we want to start seeing powerful applications
running in the browser.
If we do, then we'll figure out a way to get there. Be it installing,
It would be great to have a native binding to Zlib and Snappy exposed to
Javascript in the browser. Zlib covers the expensive disk use-cases, Snappy
covers the expensive CPU use-cases.
Also a native binding to basic crypto primitives, even if that means just SHA1
to start, and even if the
Merkle tree scheme), and
another tab for the same application needs to show data?
On 25 Jul 2011, at 8:38 PM, Jonas Sicking wrote:
On Mon, Jul 25, 2011 at 6:28 AM, Joran Greef jo...@ronomon.com wrote:
Regarding transactions in the IndexedDB specification (3.1.7 Transaction):
Once a transaction
Regarding transactions in the IndexedDB specification (3.1.7 Transaction):
Once a transaction no longer can become active, and if the transaction
hasn't been aborted, the implementation must automatically attempt to commit
it. This usually happens after all requests placed against the
On 06 Apr 2011, at 8:56 AM, Jonas Sicking wrote:
1. Treat object values as opaque (necessary to avoid
deserialization/serialization overhead, this is mandatory for storing
anything over 50,000 objects on a device like an iPad or iPhone).
Please explain this in more detail as I have no
On 06 Apr 2011, at 6:26 PM, Shawn Wilsher wrote:
On 4/4/2011 8:07 AM, Joran Greef wrote:
SQLite has a fantastic track record of maintaining backwards compatibility.
Sort of. They didn't between SQLite 2 and SQLite 3. There also have been
some (albeit minor) backwards compatibility issues
On 06 Apr 2011, at 6:49 PM, Shawn Wilsher wrote:
On 4/4/2011 10:18 AM, Joran Greef wrote:
How would you create an index on an existing object store in IndexedDB
containing more than 50,000 objects on an iPad, without incurring any object
deserialization/serialization overhead, without being
On 06 Apr 2011, at 7:14 PM, Shawn Wilsher wrote:
On 4/6/2011 9:44 AM, Joran Greef wrote:
We only need one fixed version of SQLite to be shipped across Chrome,
Safari, Opera, Firefox and IE. That in itself would represent a tremendous
goal for IndexedDB to target and to try and achieve. When
On 06 Apr 2011, at 7:24 PM, Tab Atkins Jr. wrote:
When a security bug is encountered, either the browsers update to a
new version of sqlite (if it's already been fixed), thus potentially
breaking sites, or they patch sqlite and then upgrade to the patched
version, thus potentially breaking
On 06 Apr 2011, at 7:42 PM, Boris Zbarsky wrote:
On 4/6/11 10:30 AM, Joran Greef wrote:
If Mozilla enjoys using the latest version of SQLite (and I assume they are
not planning on replacing internal SQLite embeddings with IndexedDB - not at
this stage at least), then web developers deserve
On 06 Apr 2011, at 2:53 AM, Pablo Castro wrote:
The goal of IndexedDB has always been to enable things like RelationalDB and
CouchDB to be built on top, while maintaining a reasonable level of
functionality for those that wanted to use it directly. I really like the
idea of thinking of
On 04 Apr 2011, at 4:39 PM, Jonas Sicking wrote:
Hence it would still be the case that we would be relying on the
SQLite developers to maintain a stable SQL interpretation...
SQLite has a fantastic track record of maintaining backwards compatibility.
IndexedDB has as yet no track record, no
On 04 Apr 2011, at 5:26 PM, Keean Schupke wrote:
This is ignoring the possibility that something like RelationalDB could be
used, where a well defined common subset of SQL can be used (and I use
well-defined in the formal sense). This would allow a relatively thin wrapper
on top of most
On 04 Apr 2011, at 6:10 PM, Mikeal Rogers wrote:
it's not very hard to write the abstraction you're talking about on top of
IndexedDB, and until you do it i'm going to have a hard time taking you
seriously because it's clearly doable.
You assume I have not written the abstraction I am
On 04 Apr 2011, at 6:04 PM, Tab Atkins Jr. wrote:
It's new.
Do you think it would be wise then to advocate doing away with SQLite before
IndexedDB has had a chance to prove itself? Surely two competing APIs would be
the fastest way to bring IndexedDB up to speed?
Ironically, the poor
On Sat, Apr 2, 2011 at 00:42:40, Glenn Maynard wrote:
You can certainly ask if they're interested in doing so, not for our
benefit (whoever our means), but for the benefit of the Web as a whole,
and there's nothing at all rude in asking. I'd say the opposite: it's rude
to assume they
I am incredibly uncomfortable with the idea of putting the
responsibility of the health of the web in the hands of one project.
In fact, one of the main reasons I started working at Mozilla was to
prevent this.
/ Jonas
I agree with you. All the more reason to support both WebSQL and
On 31 Mar 2011, at 1:01 AM, Jonas Sicking wrote:
Anyhow, I do think that the idea of passing in index values at the
same time as a entry is created/modified is an interesting idea. And I
have said so in the past on this list. It's definitely something we
should consider for v2.
Oh, and if
On 31 Mar 2011, at 9:53 AM, Jonas Sicking wrote:
I previously have asked for a detailed proposal, but so far you have
not supplied one but instead keep referring to other unnamed database
APIs.
I have already provided an adequate interface proposal for putObject and
deleteObject.
I have
On 31 Mar 2011, at 9:34 AM, Jeremy Orlow wrote:
We have made an effort to understand other contributions to the field.
I'm not convinced that these are essential database concepts and having
personally spent quite some time working with the API in JS and implementing
it, I feel pretty
On 31 Mar 2011, at 12:52 PM, Keean Schupke wrote:
I totally agree with everything so far...
3. This requires an adjustment to the putObject and deleteObject interfaces
(see previous threads).
I disagree that a simple API change is the answer. The problem is
architectural, not just a
On 31 Mar 2011, at 7:27 PM, Jeremy Orlow wrote:
1. Provide the application with a first-class means to manage indexes at
time of putting/deleting objects.
I'm OK with doing this for v1 if the others are. It doesn't seem like that
big of an addition and it would give a decent amount of
This is painful to read. WebSQL development died because SQLite, the most
widely-deployed database software in the world, was too good? That sounds
like a catastrophic failure of the W3C process.
--
Glenn Maynard
Hear.
I am starting to think that Mozilla will step up and provide an
criticism is due. If the specification is inadequate, or burdened by politics,
we should be free to say so (respectfully and professionally of course, but
also honestly and directly and with the right measure of urgnency), without
fear of offending anyone or being policed for it.
Joran Greef
On 31
On 31 Mar 2011, at 10:07 PM, Shawn Wilsher wrote:
On 3/31/2011 11:47 AM, Joran Greef wrote:
Let those who introduced these design flaws be among the first to take
responsibility and fix them.
You aren't being constructive, and that's a surefire way to be ignored. You
have yet to convince
On 26 Mar 2011, at 10:14 AM, Nikunj Mehta wrote:
What is the minimum that can be in IDB? I am guessing the following:
1. Sorted key-opaque value transactional store
2. Lookup of keys by values (or parts thereof)
Yes, this is what we need. In programmer speak: objects (opaque strings),
On 20 Mar 2011, at 4:54 AM, Jonas Sicking wrote:
I don't understand what you are saying about application state though,
so please do start that as a separate thread.
At present, there's no way for an application to tell IDB what indexes to
modify w.r.t. an object at the exact moment when
On 16 Mar 2011, at 7:59 PM, Jonas Sicking wrote:
The best way to do this is likely to start a new thread (as the changes you
are
suggesting isn't limited to Compound and multiple keys), and put a
draft proposal there.
It by no means has to be perfect (it took us a long time to polish
On 3/9/2011 09:45:51 Shawn Wilsher wrote:
That makes sense since the original proposal was heavily based on BDB.
It's shifted a bit as we have made tweaks to improve it for the web.
Cheers
Shawn
I agree. If I may add my two cents worth: one thing that IDB has not yet
learned from BDB
On 16 Mar 2011, at 7:59 PM, Jonas Sicking wrote:
It seems like you are suggesting pretty big changes. The best way to
do this is likely to start a new thread (as the changes you are
suggesting isn't limited to Compound and multiple keys), and put a
draft proposal there.
Not necessarily.
On 08 Mar 2011, at 7:23 AM, Dean Landolt wrote:
This doesn't seem right. Assuming your WebSQL implementation had all the same
indexes isn't it doing pretty much the same things as using separate
objectStores in IDB? Why would it be an order of magnitude slower? I'm sure
whatever
values for a given entry using arrays, as well as compound keys,
can be handled by letting the application provide an array of index references
when putting or deleting objects. There is no need to make a Rube Goldberg
device out of it.
Regards
Joran Greef
migration and data
migration) or statelessly (See Berkeley DB with the application responsible for
the complexities of data maintenance) rather than enforcing an assumption at
such an early stage.
Regards
Joran Greef
IndexedDb as a simple key value store and layer my own
indexing on top.
I am writing an email application and have to deal with secondary indexes of up
to 4,000,000 keys. It would not be ideal to do intersects and unions on these
indexes in the application layer.
Regards
Joran Greef
with be fairly soon after for both.)
Yes, for example this user object { name: Joran Greef, emails:
[jo...@ronomon.com, jorangr...@gmail.com] } with indexes on the emails
property, would be found in the jo...@ronomon.com index as well as in the
jorangr...@gmail.com index.
What I've been thinking though
Cabinet
implementation.
Joran Greef
43 matches
Mail list logo
