Well, createObjectStore is synchronous, so that one's easy. Everything
happens at once in terms of side effects.
As for delete: why is this asynchronous again? It seems easiest just to
make it sync unless there's some major problem with doing so.
Either way, it seems that the change to objectSt
On Wed, May 4, 2011 at 5:27 AM, Jonas Sicking wrote:
> On Tue, May 3, 2011 at 12:19 AM, Keean Schupke wrote:
> > The more I think about it, the more I want a user-specified comparison
> > function. Efficiency should not be an issue here - the engines should
> tweek
> > the JIT compiler to fix an
Undefined is also the return value for void functions. The result is
essentially the return value of our async methods. And in most cases, the
behavior of each async method is just a transformation of the sync method
and vice versa. So my thinking is that it should stay as it is.
J
On Mon, May
In looking at createObjectStore on IDBDatabase, it seems that we would have to
update the IDBDatabase.objectStoreNames attribute on the client side after
returning the IDBObjectStore. Otherwise, it would be difficult to detect that
an objectStore with the same name already exists and throw a CO
On Tue, May 3, 2011 at 4:45 PM, Jonas Sicking wrote:
> On Tue, May 3, 2011 at 11:51 AM, Israel Hilerio
> wrote:
> > Is this what the working group had in mind when opening this bug [1], the
> ability to add a initIDBVersionChangeEvent method to the interface below?
> >
> > interface IDBVersionChan
I'd like to bring back up the discussion that went on at [1] and [2].
In particular, I'd like to propose a minimal set of restrictions for
file names and paths, punt on the issue of what happens in later
layers of the API, and discuss case-sensitivity rules.
For the sandboxed filesystem, I propos
On Tue, May 3, 2011 at 12:19 AM, Keean Schupke wrote:
> The more I think about it, the more I want a user-specified comparison
> function. Efficiency should not be an issue here - the engines should tweek
> the JIT compiler to fix any efficiency issues. Just let the user pass a
> closure (remember
On Tue, May 3, 2011 at 11:51 AM, Israel Hilerio wrote:
> Is this what the working group had in mind when opening this bug [1], the
> ability to add a initIDBVersionChangeEvent method to the interface below?
>
> interface IDBVersionChangeEvent: Event {
> readonly attribute DOMString vers
On Tue, May 3, 2011 at 10:56 AM, Keean Schupke wrote:
> Why does it need to be persisted? I would prefer the database to be
> stateless. Obviously all users of the database need to use the same
> function.
And if they don't use exactly the same function, maybe due to a
transient bug, the index is
Ryosuke,
Le 3 mai 2011 à 21:15, Ryosuke Niwa a écrit :
>> Would it be thinkable to *lock* the copy event until either a timeout occurs
>> or an unlock is called?
> No. We definitely don't want to lock a local system resource for some random
> web service that may potentially fail to release the
On Tue, May 3, 2011 at 10:26 AM, Paul Libbrecht wrote:
>
> As noted in the thread about security started by Halvord:
>
> > In many of the scenarios I have working for, the content to be put on the
> clipboard would come from a "luxury" knowledge structure on the server, one
> that has access to so
We expect async operations to be queue up and executed in the order in which
they were created. Thus, the request to create a second transaction inside the
onsuccess handler of a setVersion request using a .transaction() method would
fail as long as we were inside a VERSION_CHANGE transaction.
Is this what the working group had in mind when opening this bug [1], the
ability to add a initIDBVersionChangeEvent method to the interface below?
interface IDBVersionChangeEvent: Event {
readonly attribute DOMString version;
--> void initIDBVersionChangeEvent(in DOMString typeA
Hello list,
As noted in the thread about security started by Halvord:
> In many of the scenarios I have working for, the content to be put on the
> clipboard would come from a "luxury" knowledge structure on the server, one
> that has access to some semantic source and can infer useful represe
Le 3 mai 2011 à 12:20, Hallvord R. M. Steen a écrit :
>> Regarding simplifying the pasted html to remove stuff that could be
>> malicious, consider a rogue app that injects a script in the clipboard and
>> expects the user to hit paste on his bank site.
>
> Well, I've never seen a bank site w
Why does it need to be persisted? I would prefer the database to be
stateless. Obviously all users of the database need to use the same
function. I would recommend modular programming - create a .js script you
can include in all pages that provides 'collated' versions of the method
calls by adding
On Tue, May 3, 2011 at 3:19 AM, Keean Schupke wrote:
> The more I think about it, the more I want a user-specified comparison
> function. Efficiency should not be an issue here - the engines should tweek
> the JIT compiler to fix any efficiency issues. Just let the user pass a
> closure (remember
On 05/03/2011 02:38 PM, Arthur Barstow wrote:
Hi All,
Pardon the interruption here to digress a bit to look at Rafael's
proposal from the process perspective ...
[Charter] defines WebApps' scope and explicit deliverables. Depending on
how the proposal is viewed, (perhaps) at least part of it co
Hi All,
Pardon the interruption here to digress a bit to look at Rafael's
proposal from the process perspective ...
[Charter] defines WebApps' scope and explicit deliverables. Depending on
how the proposal is viewed, (perhaps) at least part of it could be
rationalized by being related to XBL
On Tue, 03 May 2011 07:10:10 +0900, João Eiras
wrote:
event.clipboardData.getDocumentFragment()
which would return a parsed and when applicable sanitized view of any
markup the implementation supports from the clipboard.
This is already covered by doing
x=createElement;x.innerHTML=foo;tr
Scott Wilson wrote:
Just one more thing...
Test ta-processing2-14, "Tests that update-info element's src attribute need to be
valid, else it is ignored. The widget is not updated or replaced."
However, the value to fail with is "fail.wgt" which ought to be interpreted as
a relative URL, in
The more I think about it, the more I want a user-specified comparison
function. Efficiency should not be an issue here - the engines should tweek
the JIT compiler to fix any efficiency issues. Just let the user pass a
closure (remember functions are first-class in JavaScript so this is not a
callb
22 matches
Mail list logo
