Why is there no mechanism for paging results, a la SQL's limit? If I want
entries in positions 140-159 from an index, I have to call continue() on a
cursor 139 times, which in turn unserializes 139 objects from my store that
I don't care about, which in FF4 is making a lookup in IndexedDB
On Fri, 04 Mar 2011 01:47:35 +0100, João Eiras joao.ei...@gmail.com
wrote:
It seems Mozilla extended the interface WorkerUtils in their
implementation with the atob/btoa functions.
I find them quite useful in that context, and would also encourage
adding escape, unescape, encodeURI,
The road to least resistance seems to be using www-...@w3.org for DOM Core
discussion, as DOM Level 3 Events discussion is already taking place
there. I will at least attempt to start new threads there myself and maybe
redirect others I participate in as appropriate.
On Wed, 02 Mar 2011 06:10:47 +0100, Garrett Smith dhtmlkitc...@gmail.com
wrote:
On 3/1/11, Anne van Kesteren ann...@opera.com wrote:
These are the reasons they are intertwined:
* document.createEvent()
That was previously DocumentEvent interface, IIRC.
Implementations put it on Document
On Tue, 08 Feb 2011 10:21:52 +0100, Anne van Kesteren ann...@opera.com
wrote:
So I looked into this today and it seems that what HTML defines is not
entirely what is needed. The controls associated with the form and
extracting the form data set are separate steps rather than one
algorithm
On Tue, 08 Feb 2011 10:34:52 +0100, Anne van Kesteren ann...@opera.com
wrote:
On Sat, 13 Feb 2010 02:32:18 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Lastly, there is a bug in the spec where it says that the mimetype
should be multipart/form-data. It needs to be multipart/form-data;
On Thu, 03 Mar 2011 12:54:08 +0100, Arthur Barstow art.bars...@nokia.com
wrote:
There is significant support for this CfC and in general, I tend to
favor PEPO (publish early, publish often).
However, in this case, the group already agreed D3E is feature complete
and it would be suboptimal
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11914
Jonas Sicking jo...@sicking.cc changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, Mar 1, 2011 at 11:02 PM, Ben Dilts b...@lucidchart.com wrote:
Why is there no mechanism for paging results, a la SQL's limit? If I
want entries in positions 140-159 from an index, I have to call continue()
on a cursor 139 times, which in turn unserializes 139 objects from my store
Jeremy,
Thanks for the reply! However, my indices are not typically unique,
contiguous numbers. For example, I have an index on an item's saved date,
as a MySQL-style date/time string. These dates are not necessarily unique,
and are certainly not contiguous. So if a user is currently viewing
On Fri, Mar 4, 2011 at 11:33 AM, Ben Dilts b...@lucidchart.com wrote:
Jeremy,
Thanks for the reply! However, my indices are not typically unique,
contiguous numbers. For example, I have an index on an item's saved date,
as a MySQL-style date/time string. These dates are not necessarily
On 03/02/2011 09:02 AM, Ben Dilts wrote:
Why is there no mechanism for paging results, a la SQL's limit? If I
want entries in positions 140-159 from an index, I have to call
continue() on a cursor 139 times, which in turn unserializes 139 objects
from my store that I don't care about, which in
Firefox does lazily deserialize cursor values, so the slowdown you're
noticing is most likely due to us preserving the order of request
callbacks by queuing every continue() call in line with the rest of
the transaction. Jonas had proposed a faster, high performance cursor
that did not respect
On Fri, Mar 4, 2011 at 1:38 PM, ben turner bent.mozi...@gmail.com wrote:
Firefox does lazily deserialize cursor values, so the slowdown you're
noticing is most likely due to us preserving the order of request
callbacks by queuing every continue() call in line with the rest of
the transaction.
A few observations:
1. It seems like a fairly rare use case to have to jump to item #100
without first also observing item 1-99. When showing a paged view
which lets the user to jump directly to, say, page 5 it can certainly
happen, but the page could optimize for the case when the user first
On Fri, Mar 4, 2011 at 5:36 PM, Jonas Sicking jo...@sicking.cc wrote:
A few observations:
1. It seems like a fairly rare use case to have to jump to item #100
without first also observing item 1-99. When showing a paged view
which lets the user to jump directly to, say, page 5 it can
Like I said, I agree that we need to do something to allow for more
powerful indexes. We already have two options for allowing essentially
arbitrary indexes:
1. Use a separate objectStore which is manually managed.
2. Modify the object before inserting it to add a special property
which can then
17 matches
Mail list logo
