uot; that
would keep the transaction alive for a certain amount of time.
Joran Greef
On 17 Sep 2012, at 2:33 PM, Florian Bösch 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
click).
> No TC
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
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
hav
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 tab
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",
"permiss
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 Node.
> On 03 Aug 2011, at 7:33 PM, Jonas Sicking wrote:
>
"Note that reads are also blocked if the long-running transaction is a
READ_WRITE transaction."
>>
>> Is it acceptable for a writer to block readers? What if one tab is
>> downloading a gigabyte of user data (using a workload-config
rs? What if one tab is downloading
a gigabyte of user data (using a workload-configurable 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 wrote:
> Regarding transactions i
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 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)
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: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
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/s
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) bac
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 ha
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 7:28 PM, Mikeal Rogers wrote:
> the biggest bottleneck here in the current implementation would be the
> transaction overhead on a database this size, which is because of performance
> problems in sqlite which is underlying the implementation. sqlite can't fix
> this, it's cu
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 perfo
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 ta
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 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
> 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 I
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
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 ignore
n these issues where
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
> 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
On 31 Mar 2011, at 7:41 PM, Jonas Sicking wrote:
> So pretty please, with sugar on top, please come up with a proposal
> for the full API rather than bits and pieces.
Let those who introduced these design flaws be among the first to take
responsibility and fix them.
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
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 j
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 pr
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 a
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
> 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 whe
> 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
> 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 necessar
> 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 f
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 impleme
d.
Multiple index 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
ities of schema 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
On 02 Mar 2011, at 1:31 PM, Jonas Sicking wrote:
> I agree that we are currently enforcing a bit of schema due to the way
> indexes work. However I think it's a good approach for an initial
> version of this API as it covers the most simple use cases. Note that
> the more complex use cases are sti
ne in the next version of each, and
> hopefully that release 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, wou
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
g to avoid file upload forms, and temp file downloads. I'm not sure these
goals are possible with the current spec?
These use-cases may prove to be vital building blocks for the next wave of
networked applications and it would be great to see them in the new FileSystem
API.
Regards
Joran Greef
han the current Tokyo Cabinet
implementation.
Joran Greef
48 matches
Mail list logo
