Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Jeremy Orlow]

Actually, what's the use case for readyState?  I can't think of any uses
that we'd want to encourage.  Maybe we should just remove it.

J

On Wed, Aug 25, 2010 at 3:50 PM,  wrote:

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10430
>
>   Summary: [IndexedDB] We need to make it more clear IDBRequests
>can be reused and spec readyState's behavior
>   Product: WebAppsWG
>   Version: unspecified
>  Platform: PC
>OS/Version: All
>Status: NEW
>  Severity: normal
>  Priority: P2
> Component: Indexed Database API
>AssignedTo: andr...@google.com
>ReportedBy: jor...@chromium.org
> QAContact: member-webapi-...@w3.org
>CC: m...@w3.org, public-webapps@w3.org
>
>
> http://www.w3.org/TR/IndexedDB/#idl-def-IDBRequest right now clearly
> assumes
> IDBRequests are only going to be used once.  But IDBCursor.continue()
> reuses
> them.  At the very least, we'll need to clean up the .readyState section to
> make it clear it's possible to go from DONE to LOADING (or we can remove it
> altogether?).  I think some notes explicitly pointing out that some parts
> of
> the API reuse them would be helpful as well.
>
> --
> Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>
>

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Jonas Sicking]

On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow  wrote:
> Actually, what's the use case for readyState?  I can't think of any uses
> that we'd want to encourage.  Maybe we should just remove it.

The use-case that I've heard in similar situations goes something like this:

Code makes a request and at some point later hands the request to some
other piece of code which is interested in the result.
The other piece of code doesn't necessarily know if a result has been
returned yet or not. Using readyState it can either simply get
.result, or it can add a event listener for the "success" event and
wait for the event to fire.

I think that makes sense here too.

/ Jonas

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Jeremy Orlow]

On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking  wrote:

> On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow  wrote:
> > Actually, what's the use case for readyState?  I can't think of any uses
> > that we'd want to encourage.  Maybe we should just remove it.
>
> The use-case that I've heard in similar situations goes something like
> this:
>
> Code makes a request and at some point later hands the request to some
> other piece of code which is interested in the result.
> The other piece of code doesn't necessarily know if a result has been
> returned yet or not. Using readyState it can either simply get
> .result, or it can add a event listener for the "success" event and
> wait for the event to fire.
>
> I think that makes sense here too.
>

What about the cursor case though?  Given that we're re-using the same
request object, I really don't think it makes much sense.

J

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Jonas Sicking]

On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow  wrote:
> On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking  wrote:
>>
>> On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow  wrote:
>> > Actually, what's the use case for readyState?  I can't think of any uses
>> > that we'd want to encourage.  Maybe we should just remove it.
>>
>> The use-case that I've heard in similar situations goes something like
>> this:
>>
>> Code makes a request and at some point later hands the request to some
>> other piece of code which is interested in the result.
>> The other piece of code doesn't necessarily know if a result has been
>> returned yet or not. Using readyState it can either simply get
>> .result, or it can add a event listener for the "success" event and
>> wait for the event to fire.
>>
>> I think that makes sense here too.
>
> What about the cursor case though?  Given that we're re-using the same
> request object, I really don't think it makes much sense.

It makes sense if the code the request is passed to is the one calling
continue(), no?

/ Jonas

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Jeremy Orlow]

On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking  wrote:

> On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow  wrote:
> > On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking  wrote:
> >>
> >> On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow 
> wrote:
> >> > Actually, what's the use case for readyState?  I can't think of any
> uses
> >> > that we'd want to encourage.  Maybe we should just remove it.
> >>
> >> The use-case that I've heard in similar situations goes something like
> >> this:
> >>
> >> Code makes a request and at some point later hands the request to some
> >> other piece of code which is interested in the result.
> >> The other piece of code doesn't necessarily know if a result has been
> >> returned yet or not. Using readyState it can either simply get
> >> .result,
>

Actually, this isn't possible.  As first proposed by Ben in "Changes to
IDBRequest and specification of the success and error events",
IDBRequest.result was moved just to the success event.  So there is no way
for something to access the result except through an onsuccess event
handler.  So the only use case for readyState is figuring out if you need to
re-issue a request.


> or it can add a event listener for the "success" event and
> >> wait for the event to fire.
> >>
> >> I think that makes sense here too.
> >
> > What about the cursor case though?  Given that we're re-using the same
> > request object, I really don't think it makes much sense.
>
> It makes sense if the code the request is passed to is the one calling
> continue(), no?
>

What's the use case for this though?  It seems awfully odd that a cursor
would be getting passed around after some async call after returning to the
event loop.  If you haven't returned to the event loop since your last call,
then there's no need to check ready state.  And things of course become very
confusing if you're issued multiple calls.

Which brings up the point: what's the behavior if you call .continue()
twice?  Will your on success fire twice?  What if the first result was null
(because you're out of results).  Should onsuccess fire twice with nulls or
only one null and ignore any subsequent continue() requests?

Btw, if we do keep readyState around, we should specify that its state
changing should be done via the event loop to maintain run to completion
semantics.

J

P.S. I'm happy to discuss all of this f2f tomorrow rather than over email
now.

[Workers] NavigatorOnLine

[Olli Pettay]

Hi all,

Workers seem to use NavigatorOnLine, but it is not specified
whether online/offline events should be dispatched.
I think they should be, since otherwise tracking the changes to
.onLine is hard.


-Olli

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Jonas Sicking]

On Mon, Nov 1, 2010 at 3:18 AM, Jeremy Orlow  wrote:
> On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking  wrote:
>>
>> On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow  wrote:
>> > On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking  wrote:
>> >>
>> >> On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow 
>> >> wrote:
>> >> > Actually, what's the use case for readyState?  I can't think of any
>> >> > uses
>> >> > that we'd want to encourage.  Maybe we should just remove it.
>> >>
>> >> The use-case that I've heard in similar situations goes something like
>> >> this:
>> >>
>> >> Code makes a request and at some point later hands the request to some
>> >> other piece of code which is interested in the result.
>> >> The other piece of code doesn't necessarily know if a result has been
>> >> returned yet or not. Using readyState it can either simply get
>> >> .result,
>
> Actually, this isn't possible.  As first proposed by Ben in "Changes to
> IDBRequest and specification of the success and error events",
> IDBRequest.result was moved just to the success event.  So there is no way
> for something to access the result except through an onsuccess event
> handler.  So the only use case for readyState is figuring out if you need to
> re-issue a request.

Good point, will have to think about that some more.

>> or it can add a event listener for the "success" event and
>> >> wait for the event to fire.
>> >>
>> >> I think that makes sense here too.
>> >
>> > What about the cursor case though?  Given that we're re-using the same
>> > request object, I really don't think it makes much sense.
>>
>> It makes sense if the code the request is passed to is the one calling
>> continue(), no?
>
> What's the use case for this though?  It seems awfully odd that a cursor
> would be getting passed around after some async call after returning to the
> event loop.  If you haven't returned to the event loop since your last call,
> then there's no need to check ready state.  And things of course become very
> confusing if you're issued multiple calls.

Consider code that performs some type of merge for example. Placing
several requests to different object stores and waiting for response
from all of them.

> Which brings up the point: what's the behavior if you call .continue()
> twice?  Will your on success fire twice?  What if the first result was null
> (because you're out of results).  Should onsuccess fire twice with nulls or
> only one null and ignore any subsequent continue() requests?

I think that a call to .continue() on a cursor which still hasn't
returned a result from the last call to continue() should result in a
NOT_ALLOWED_ERR being thrown. There is just no logical way to honor
two calls running at once, so I think the second call should either
throw or do nothing.

> P.S. I'm happy to discuss all of this f2f tomorrow rather than over email
> now.

Speaking of which, would be great to have an agenda. Some of the
bigger items are:

* Dynamic transactions
* Arrays-as-keys
* Arrays and indexes (what to do if the keyPath for an index evaluates
to an array)
* Synchronous API

/ Jonas

IndexedDB TPAC agenda

[Jeremy Orlow]

What items should we try to cover during the f2f?

On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking  wrote:
>
>  > P.S. I'm happy to discuss all of this f2f tomorrow rather than over
> email
> > now.
>
> Speaking of which, would be great to have an agenda. Some of the
> bigger items are:
>
> * Dynamic transactions
> * Arrays-as-keys
> * Arrays and indexes (what to do if the keyPath for an index evaluates
> to an array)
> * Synchronous API
>

* Compound keys.
* What should be allowed in a keyPath.

I'm sure I'll think of more.  We'll probably have more items to cover than
we can actually get done, so let's plan on tackling the items that are more
up in the air and/or require more discussion/debate first.  We can then use
the mailing list for whatever we don't get to.

J

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Jeremy Orlow]

On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking  wrote:

> On Mon, Nov 1, 2010 at 3:18 AM, Jeremy Orlow  wrote:
> > On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking  wrote:
> >>
> >> On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow 
> wrote:
> >> > On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking 
> wrote:
> >> >>
> >> >> On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow 
> >> >> wrote:
> >> >> > Actually, what's the use case for readyState?  I can't think of any
> >> >> > uses
> >> >> > that we'd want to encourage.  Maybe we should just remove it.
> >> >>
> >> >> The use-case that I've heard in similar situations goes something
> like
> >> >> this:
> >> >>
> >> >> Code makes a request and at some point later hands the request to
> some
> >> >> other piece of code which is interested in the result.
> >> >> The other piece of code doesn't necessarily know if a result has been
> >> >> returned yet or not. Using readyState it can either simply get
> >> >> .result,
> >
> > Actually, this isn't possible.  As first proposed by Ben in "Changes to
> > IDBRequest and specification of the success and error events",
> > IDBRequest.result was moved just to the success event.  So there is no
> way
> > for something to access the result except through an onsuccess event
> > handler.  So the only use case for readyState is figuring out if you need
> to
> > re-issue a request.
>
> Good point, will have to think about that some more.
>
> >> or it can add a event listener for the "success" event and
> >> >> wait for the event to fire.
> >> >>
> >> >> I think that makes sense here too.
> >> >
> >> > What about the cursor case though?  Given that we're re-using the same
> >> > request object, I really don't think it makes much sense.
> >>
> >> It makes sense if the code the request is passed to is the one calling
> >> continue(), no?
> >
> > What's the use case for this though?  It seems awfully odd that a cursor
> > would be getting passed around after some async call after returning to
> the
> > event loop.  If you haven't returned to the event loop since your last
> call,
> > then there's no need to check ready state.  And things of course become
> very
> > confusing if you're issued multiple calls.
>
> Consider code that performs some type of merge for example. Placing
> several requests to different object stores and waiting for response
> from all of them.
>

So you're assuming that it'd set the same onsuccess handler for multiple
cursors and then check the ready state of them all upon each call and only
do processing when they're all ready?  If so, you can do this other ways
(use a counter or wait until you've gotten a call from each event.source you
expect), and this solution doesn't seem particularly more elegant to me.  If
not, I don't understand this use case.

Either way, I'm pretty sure this isn't an example of "a cursor would be
getting passed around after some async call after returning to the event
loop" which I believe is the only use case where ready state would actually
be necessary.


> > Which brings up the point: what's the behavior if you call .continue()
> > twice?  Will your on success fire twice?  What if the first result was
> null
> > (because you're out of results).  Should onsuccess fire twice with nulls
> or
> > only one null and ignore any subsequent continue() requests?
>
> I think that a call to .continue() on a cursor which still hasn't
> returned a result from the last call to continue() should result in a
> NOT_ALLOWED_ERR being thrown. There is just no logical way to honor
> two calls running at once, so I think the second call should either
> throw or do nothing.


Throw is much better than do nothing.  I think that's best for now, and we
can spec the behavior in the future if there's demand.  I'll file a bug.

You didn't respond to "Btw, if we do keep readyState around, we should
specify that its state changing should be done via the event loop to
maintain run to completion semantics."  Would you agree?

> P.S. I'm happy to discuss all of this f2f tomorrow rather than over email
> > now.
>
> Speaking of which, would be great to have an agenda. Some of the
> bigger items are:
>
> * Dynamic transactions
> * Arrays-as-keys
> * Arrays and indexes (what to do if the keyPath for an index evaluates
> to an array)
> * Synchronous API
>

I forked this into another thread.  Let's discuss there please.

J

[Bug 11187] New: [IndexedDB] Repeated calls to IDBCursor.continue() should throw

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11187

   Summary: [IndexedDB] Repeated calls to IDBCursor.continue()
should throw
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: andr...@google.com
ReportedBy: jor...@chromium.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


If IDBCursor.continue() is called after a previous .continue() call but before
its onsuccess/onerror call, we should throw a NOT_ALLOWED_ERR.  This was
discuseed on list in replies to bug 10430's filing.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: IndexedDB TPAC agenda

[Jonas Sicking]

On Mon, Nov 1, 2010 at 4:40 AM, Jeremy Orlow  wrote:
> What items should we try to cover during the f2f?
> On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking  wrote:
>>
>> > P.S. I'm happy to discuss all of this f2f tomorrow rather than over
>> > email
>> > now.
>>
>> Speaking of which, would be great to have an agenda. Some of the
>> bigger items are:
>>
>> * Dynamic transactions
>> * Arrays-as-keys
>> * Arrays and indexes (what to do if the keyPath for an index evaluates
>> to an array)
>> * Synchronous API
>
> * Compound keys.
> * What should be allowed in a keyPath.

Aren't "compound keys" same as "arrays-as-keys"?

* What should happen if an index's keyPath points to a property which
doesn't exist or which isn't a valid key-value? (same general topic as
"arrays and indexes" above)
* What happens if the user leaves a page in the middle of a
transaction? (this might be nice to tackle since there'll be lots of
relevant people in the room)
* Error handling

> I'm sure I'll think of more.  We'll probably have more items to cover than
> we can actually get done, so let's plan on tackling the items that are more
> up in the air and/or require more discussion/debate first.  We can then use
> the mailing list for whatever we don't get to.

Agreed.

/ Jonas

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Jonas Sicking]

On Mon, Nov 1, 2010 at 4:49 AM, Jeremy Orlow  wrote:
>
>
> On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking  wrote:
>>
>> On Mon, Nov 1, 2010 at 3:18 AM, Jeremy Orlow  wrote:
>> > On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking  wrote:
>> >>
>> >> On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow 
>> >> wrote:
>> >> > On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking 
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow 
>> >> >> wrote:
>> >> >> > Actually, what's the use case for readyState?  I can't think of
>> >> >> > any
>> >> >> > uses
>> >> >> > that we'd want to encourage.  Maybe we should just remove it.
>> >> >>
>> >> >> The use-case that I've heard in similar situations goes something
>> >> >> like
>> >> >> this:
>> >> >>
>> >> >> Code makes a request and at some point later hands the request to
>> >> >> some
>> >> >> other piece of code which is interested in the result.
>> >> >> The other piece of code doesn't necessarily know if a result has
>> >> >> been
>> >> >> returned yet or not. Using readyState it can either simply get
>> >> >> .result,
>> >
>> > Actually, this isn't possible.  As first proposed by Ben in "Changes to
>> > IDBRequest and specification of the success and error events",
>> > IDBRequest.result was moved just to the success event.  So there is no
>> > way
>> > for something to access the result except through an onsuccess event
>> > handler.  So the only use case for readyState is figuring out if you
>> > need to
>> > re-issue a request.
>>
>> Good point, will have to think about that some more.
>>
>> >> or it can add a event listener for the "success" event and
>> >> >> wait for the event to fire.
>> >> >>
>> >> >> I think that makes sense here too.
>> >> >
>> >> > What about the cursor case though?  Given that we're re-using the
>> >> > same
>> >> > request object, I really don't think it makes much sense.
>> >>
>> >> It makes sense if the code the request is passed to is the one calling
>> >> continue(), no?
>> >
>> > What's the use case for this though?  It seems awfully odd that a cursor
>> > would be getting passed around after some async call after returning to
>> > the
>> > event loop.  If you haven't returned to the event loop since your last
>> > call,
>> > then there's no need to check ready state.  And things of course become
>> > very
>> > confusing if you're issued multiple calls.
>>
>> Consider code that performs some type of merge for example. Placing
>> several requests to different object stores and waiting for response
>> from all of them.
>
> So you're assuming that it'd set the same onsuccess handler for multiple
> cursors and then check the ready state of them all upon each call and only
> do processing when they're all ready?  If so, you can do this other ways
> (use a counter or wait until you've gotten a call from each event.source you
> expect), and this solution doesn't seem particularly more elegant to me.  If
> not, I don't understand this use case.

I don't really agree that a counter is more elegant. It's also more
complicated as you start iterating over the various cursors as you'll
then have to wait for a different number of cursors depending on the
values that you find.

> Either way, I'm pretty sure this isn't an example of "a cursor would be
> getting passed around after some async call after returning to the event
> loop" which I believe is the only use case where ready state would actually
> be necessary.

Why is it not? Calling .continue() on another cursor is async.

>> > Which brings up the point: what's the behavior if you call .continue()
>> > twice?  Will your on success fire twice?  What if the first result was
>> > null
>> > (because you're out of results).  Should onsuccess fire twice with nulls
>> > or
>> > only one null and ignore any subsequent continue() requests?
>>
>> I think that a call to .continue() on a cursor which still hasn't
>> returned a result from the last call to continue() should result in a
>> NOT_ALLOWED_ERR being thrown. There is just no logical way to honor
>> two calls running at once, so I think the second call should either
>> throw or do nothing.
>
> Throw is much better than do nothing.  I think that's best for now, and we
> can spec the behavior in the future if there's demand.  I'll file a bug.

Thanks. I'll fix it as part of my current cursor-reworking patch.

> You didn't respond to "Btw, if we do keep readyState around, we should
> specify that its state changing should be done via the event loop to
> maintain run to completion semantics."  Would you agree?

I don't really agree. Run-to-completion doesn't state that properties
can't change during the execution of a specific thread. It states that
properties shouldn't change in response to background threads and the
like. Compare to XMLHttpRequest.readyState which changes synchronously
in response to a call .open().

Or simply compare to window.foo = "bar";

/ Jonas

Re: IndexedDB TPAC agenda

[Jeremy Orlow]

On Mon, Nov 1, 2010 at 11:53 AM, Jonas Sicking  wrote:

> On Mon, Nov 1, 2010 at 4:40 AM, Jeremy Orlow  wrote:
> > What items should we try to cover during the f2f?
> > On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking  wrote:
> >>
> >> > P.S. I'm happy to discuss all of this f2f tomorrow rather than over
> >> > email
> >> > now.
> >>
> >> Speaking of which, would be great to have an agenda. Some of the
> >> bigger items are:
> >>
> >> * Dynamic transactions
> >> * Arrays-as-keys
> >> * Arrays and indexes (what to do if the keyPath for an index evaluates
> >> to an array)
> >> * Synchronous API
> >
> > * Compound keys.
> > * What should be allowed in a keyPath.
>
> Aren't "compound keys" same as "arrays-as-keys"?
>

Sorry, I meant to say compound indexes.

We've talked about using indexes in many different ways--including compound
indexes and allowing keys to include indexes.  I assumed you meant the
latter?


> * What should happen if an index's keyPath points to a property which
> doesn't exist or which isn't a valid key-value? (same general topic as
> "arrays and indexes" above)
>

We've talked about this several times.  It'd be great to settle on something
once and for all.


> * What happens if the user leaves a page in the middle of a
> transaction? (this might be nice to tackle since there'll be lots of
> relevant people in the room)
>

I'm pretty sure this is simple: if there's an onsuccess/onerror handler that
has not yet fired (or we're in the middle of firing), then you abort the
transaction.  If not, the behavior is undefined (because there's no way the
app could have observed the difference anyway).  The aborting behavior is
necessary since the user could have planned to execute additional commands
atomically in the handler.


> * Error handling


What do you mean by this?

J

Re: IndexedDB TPAC agenda

[Jonas Sicking]

On Mon, Nov 1, 2010 at 5:13 AM, Jeremy Orlow  wrote:
> On Mon, Nov 1, 2010 at 11:53 AM, Jonas Sicking  wrote:
>>
>> On Mon, Nov 1, 2010 at 4:40 AM, Jeremy Orlow  wrote:
>> > What items should we try to cover during the f2f?
>> > On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking  wrote:
>> >>
>> >> > P.S. I'm happy to discuss all of this f2f tomorrow rather than over
>> >> > email
>> >> > now.
>> >>
>> >> Speaking of which, would be great to have an agenda. Some of the
>> >> bigger items are:
>> >>
>> >> * Dynamic transactions
>> >> * Arrays-as-keys
>> >> * Arrays and indexes (what to do if the keyPath for an index evaluates
>> >> to an array)
>> >> * Synchronous API
>> >
>> > * Compound keys.
>> > * What should be allowed in a keyPath.
>>
>> Aren't "compound keys" same as "arrays-as-keys"?
>
> Sorry, I meant to say compound indexes.
> We've talked about using indexes in many different ways--including compound
> indexes and allowing keys to include indexes.  I assumed you meant the
> latter?

I'm lost as to what you're saying here. Could you elaborate? Are you
saying "index" when you mean "array" anywhere?

>> * What should happen if an index's keyPath points to a property which
>> doesn't exist or which isn't a valid key-value? (same general topic as
>> "arrays and indexes" above)
>
> We've talked about this several times.  It'd be great to settle on something
> once and for all.

Agreed.

>> * What happens if the user leaves a page in the middle of a
>> transaction? (this might be nice to tackle since there'll be lots of
>> relevant people in the room)
>
> I'm pretty sure this is simple: if there's an onsuccess/onerror handler that
> has not yet fired (or we're in the middle of firing), then you abort the
> transaction.  If not, the behavior is undefined (because there's no way the
> app could have observed the difference anyway).  The aborting behavior is
> necessary since the user could have planned to execute additional commands
> atomically in the handler.

There is also the option to let the transaction finish. They should be
short-lived so it shouldn't be too bad.

>> * Error handling
>
> What do you mean by this?

How to handle exceptions in various places. Where (error) events
propagate. How does it relate to window.onerror. What happens if you
do/don't call preventDefault on the error event?

/ Jonas

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Jeremy Orlow]

On Mon, Nov 1, 2010 at 12:00 PM, Jonas Sicking  wrote:

> On Mon, Nov 1, 2010 at 4:49 AM, Jeremy Orlow  wrote:
> >
> >
> > On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking  wrote:
> >>
> >> On Mon, Nov 1, 2010 at 3:18 AM, Jeremy Orlow 
> wrote:
> >> > On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking 
> wrote:
> >> >>
> >> >> On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow 
> >> >> wrote:
> >> >> > On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking 
> >> >> > wrote:
> >> >> >>
> >> >> >> On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow  >
> >> >> >> wrote:
> >> >> >> > Actually, what's the use case for readyState?  I can't think of
> >> >> >> > any
> >> >> >> > uses
> >> >> >> > that we'd want to encourage.  Maybe we should just remove it.
> >> >> >>
> >> >> >> The use-case that I've heard in similar situations goes something
> >> >> >> like
> >> >> >> this:
> >> >> >>
> >> >> >> Code makes a request and at some point later hands the request to
> >> >> >> some
> >> >> >> other piece of code which is interested in the result.
> >> >> >> The other piece of code doesn't necessarily know if a result has
> >> >> >> been
> >> >> >> returned yet or not. Using readyState it can either simply get
> >> >> >> .result,
> >> >
> >> > Actually, this isn't possible.  As first proposed by Ben in "Changes
> to
> >> > IDBRequest and specification of the success and error events",
> >> > IDBRequest.result was moved just to the success event.  So there is no
> >> > way
> >> > for something to access the result except through an onsuccess event
> >> > handler.  So the only use case for readyState is figuring out if you
> >> > need to
> >> > re-issue a request.
> >>
> >> Good point, will have to think about that some more.
> >>
> >> >> or it can add a event listener for the "success" event and
> >> >> >> wait for the event to fire.
> >> >> >>
> >> >> >> I think that makes sense here too.
> >> >> >
> >> >> > What about the cursor case though?  Given that we're re-using the
> >> >> > same
> >> >> > request object, I really don't think it makes much sense.
> >> >>
> >> >> It makes sense if the code the request is passed to is the one
> calling
> >> >> continue(), no?
> >> >
> >> > What's the use case for this though?  It seems awfully odd that a
> cursor
> >> > would be getting passed around after some async call after returning
> to
> >> > the
> >> > event loop.  If you haven't returned to the event loop since your last
> >> > call,
> >> > then there's no need to check ready state.  And things of course
> become
> >> > very
> >> > confusing if you're issued multiple calls.
> >>
> >> Consider code that performs some type of merge for example. Placing
> >> several requests to different object stores and waiting for response
> >> from all of them.
> >
> > So you're assuming that it'd set the same onsuccess handler for multiple
> > cursors and then check the ready state of them all upon each call and
> only
> > do processing when they're all ready?  If so, you can do this other ways
> > (use a counter or wait until you've gotten a call from each event.source
> you
> > expect), and this solution doesn't seem particularly more elegant to me.
>  If
> > not, I don't understand this use case.
>
> I don't really agree that a counter is more elegant.


I said "doesn't seem particularly more elegant to me".  In other words, I
don't think it's enough more elegant that it's worth the additional API
surface area.


> It's also more
> complicated as you start iterating over the various cursors as you'll
> then have to wait for a different number of cursors depending on the
> values that you find.
>

I'm not really following you.  I guess in SQL terms you're talking about
left/outter joins?


>  > Either way, I'm pretty sure this isn't an example of "a cursor would be
> > getting passed around after some async call after returning to the event
> > loop" which I believe is the only use case where ready state would
> actually
> > be necessary.
>
> Why is it not? Calling .continue() on another cursor is async.
>

I said "be necessary".  I'm pretty sure code composability _after returning
to the event loop_ is the only use case where a readyState would be
_necessary_.  I'd love to hear a concrete example of why someone might need
to do this.

As for it being convenient, I don't think think your example is that much
more convenient than other possible ways of doing it.  Have any developers
actually done something like this and found it painful?  Is there any code
you can point us to that would make the scenario more concrete and clear?
 If not, I think we should avoid adding surface area for something we don't
really understand very well.

J

Re: IndexedDB TPAC agenda

[Jeremy Orlow]

On Mon, Nov 1, 2010 at 12:23 PM, Jonas Sicking  wrote:

> On Mon, Nov 1, 2010 at 5:13 AM, Jeremy Orlow  wrote:
> > On Mon, Nov 1, 2010 at 11:53 AM, Jonas Sicking  wrote:
> >>
> >> On Mon, Nov 1, 2010 at 4:40 AM, Jeremy Orlow 
> wrote:
> >> > What items should we try to cover during the f2f?
> >> > On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking 
> wrote:
> >> >>
> >> >> > P.S. I'm happy to discuss all of this f2f tomorrow rather than over
> >> >> > email
> >> >> > now.
> >> >>
> >> >> Speaking of which, would be great to have an agenda. Some of the
> >> >> bigger items are:
> >> >>
> >> >> * Dynamic transactions
> >> >> * Arrays-as-keys
> >> >> * Arrays and indexes (what to do if the keyPath for an index
> evaluates
> >> >> to an array)
> >> >> * Synchronous API
> >> >
> >> > * Compound keys.
> >> > * What should be allowed in a keyPath.
> >>
> >> Aren't "compound keys" same as "arrays-as-keys"?
> >
> > Sorry, I meant to say compound indexes.
> > We've talked about using indexes in many different ways--including
> compound
> > indexes and allowing keys to include indexes.  I assumed you meant the
> > latter?
>
> I'm lost as to what you're saying here. Could you elaborate? Are you
> saying "index" when you mean "array" anywhere?
>

oops.  Yes, I meant to say: "We've talked about using arrays in many
different ways--including compound indexes and allowing keys to include
arrays.  I assumed you meant the latter?"


> >> * What should happen if an index's keyPath points to a property which
> >> doesn't exist or which isn't a valid key-value? (same general topic as
> >> "arrays and indexes" above)
> >
> > We've talked about this several times.  It'd be great to settle on
> something
> > once and for all.
>
> Agreed.
>
> >> * What happens if the user leaves a page in the middle of a
> >> transaction? (this might be nice to tackle since there'll be lots of
> >> relevant people in the room)
> >
> > I'm pretty sure this is simple: if there's an onsuccess/onerror handler
> that
> > has not yet fired (or we're in the middle of firing), then you abort the
> > transaction.  If not, the behavior is undefined (because there's no way
> the
> > app could have observed the difference anyway).  The aborting behavior is
> > necessary since the user could have planned to execute additional
> commands
> > atomically in the handler.
>
> There is also the option to let the transaction finish. They should be
> short-lived so it shouldn't be too bad.
>

I.e. keep the page alive for a bit longer in the background or something
that blocks page unload?  Is there precedent for this elsewhere?  This
sounds pretty complicated to get right both in terms of implementation and
speccing.  Let's chat about it though.


> >> * Error handling
> >
> > What do you mean by this?
>
> How to handle exceptions in various places. Where (error) events
> propagate. How does it relate to window.onerror. What happens if you
> do/don't call preventDefault on the error event?
>


Sounds good.

Widgets and OAuth or other similar redirect-based protocols

[Bryan Sullivan]

Hi,
Can anyone point to an example of how to use HTTP redirect-based protocols
such as OAuth with widgets? There seem to be issues with the use of these
protocols due to the difference between widgets and browser-based webapps,
in particular with the two aspects:
* widgets cannot access network resources unless an access
request/dependency to the domain is declared per the WARP spec. Thus any
domain that is to be used in a redirect-based protocol needs to be known
up-front and explicitly included per WARP.
* for widgets, there is no ³origin² or at least ³base² that can be used in a
redirect-based protocol. All that widgets could expose for redirect purposes
are relative URIs for their resources. Thus redirect protocols/designs in
which one widget page makes a request which is intended to result in a
redirect to another widget page, will not work.

An example of how to do this for widgets, e.g. a Twitter-enabled widget (as
Twitter uses OAuth) would be very helpful.

It does seem that applications using XHR for this (as compared to web
links/anchors etc) would/should be in total control of the operation of XHR,
but they would need to handle all HTTP requests and responses (including
redirects).

Apologies in advance if this request is not clear from a technical
perspective. 

Bryan

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

[Shawn Wilsher]

On 11/1/2010 5:29 AM, Jeremy Orlow wrote:

  If not, I think we should avoid adding surface area for something we don't
really understand very well.
I agree with this.  Less is better at this point I think (when 
appropriate, of course).


Cheers,

Shawn



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [IndexedDB] IDBKeyRange cleanup

[Jeremy Orlow]

On Sat, Oct 30, 2010 at 12:24 AM, Jonas Sicking  wrote:

> On Sun, Oct 24, 2010 at 8:06 AM, Jeremy Orlow  wrote:
> > On Sat, Oct 23, 2010 at 2:45 AM, Jonas Sicking  wrote:
> >>
> >> Hi all,
> >>
> >> IDBKeyRange is in need of some cleanup. The first issue is its
> >> constructors. Currently the IDL for IDBKeyRange, define that the
> >> constructors, .only, .leftBound, .rightBound, .bound, on object
> >> instances themselves. I don't think this is intentional since first of
> >> all it makes it impossible to create the first IDBKeyRange, second,
> >> second it seems strange to have constructor functions on instances.
> >>
> >> It seems like the intent is that the following should work:
> >>
> >> x = new IDBKeyRange.bound(...);
> >> and possibly also
> >> x = IDBKeyRange.bound(...);
> >> (the latter works for for example XMLHttpRequest, JS-heads have also
> >> informed me that it should work).
> >
> > The latter is what we do in Chromium and what I'm pretty sure we agreed
> upon
> > in earlier threads.  Since these methods are factories, it seems as
> though
> > the new operator should not be necessary.
> >
> >>
> >> Unfortunately there is no way to express this in WebIDL, so I think we
> >> need to describe it in prose instead. I'll raise this with Cameron,
> >> but I think that since at this point only IndexedDB uses these
> >> "static" functions, it might not make sense to add support to WebIDL.
> >
> > I believe "class methods" is the more accepted term for such methods.
>  I'd
> > rather we look at adding these to WebIDL now rather than waiting for the
> > next instance that uses them as I'd hope we didn't add a new concept just
> > for one interface in one API.  Prose seems like the right solution in the
> > mean time though.
> >
> >>
> >> The other thing is that the .flags attribute is really not very
> >> javascript friendly as it uses bitfields. It also is weird in that it
> >> has multiple bits, but some have strong interdependencies. For example
> >> if SINGLE is set LEFT_OPEN and RIGHT_OPEN must be false, and
> >> LEFT_BOUND and RIGHT_BOUND must be true. It also seems like the
> >> LEFT_BOUND flag is closely correlated to the .left property.
> >>
> >> I suggest the following API instead:
> >>
> >> interface IDBKeyRange {
> >>  readonly attribute any left;
> >>  readonly attribute any right;
> >>  readonly attribute boolean leftOpen;
> >>  readonly attribute boolean rightOpen;
> >> };
> >>
> >> the .left and .right properties return 'null' or 'undefined' (to be
> >> discussed) when the keyrange isn't bound in that direction.
> >
> > I agree the flags attribute is confusing and not very JavaScript like.  I
> > also like your solution.  null is probably what it should return when not
> > bounded.
>

Why did you end up using undefined rather than null?  "The key range
lower value is
undefined or less than key value."


> > What should the open param return if its associated left/right is not
> bound?
> >  I don't care much, but it should definitely be specced.
> >>
> >> Another question I had is if "left" and "right" really are good names.
> >> Seems to me that "upper" and "lower" are better words, but it might be
> >> that left/right is established concepts in the database community? I
> >> don't feel strongly on this issue. Oh, I see now that bug 10397 is
> >> filed on this exact issue.
> >
> > Yup.  Agree that left/right are bad names.
> > The fact that we're discussing things over again points to the fact that
> we
> > really need to get on top of all the bugs against the spec.  Most of them
> > should be pretty easy.  Will the editors have time to address these
> before
> > TPAC?  If not, does anyone have a problem with me becoming an editor?
> >
> >>
> >> Lastly, should we allow values to be passed directly to all APIs that
> >> currently take IDBKeyRanges? It seems nice to not require people to
> >> create an IDBKeyRange object using patterns like:
> >>
> >> req = objectStore.openCursor(new IDBKeyRange.only(foo));
> >>
> >> and instead allow
> >>
> >> req = objectStore.openCursor(foo);
> >
> > I'm OK with this.
> >
> >>
> >> Similarly, should we allow IDBObjectStore.get on and IDBIndex.get to
> >> take a IDBKeyRange and return the first value that matches the
> >> keyrange. This would allow things like "give me the first entry with a
> >> value greater than X".
> >
> > That seems like it could be valuable.  I'd support such a change.
>
> I've implemented these changes in
> http://dvcs.w3.org/hg/IndexedDB/rev/e5a08025e518
>
> There is definitely a lot of work remaining on the spec. I've added a
> lot of infrastructure which should make this *much* easier, such as
> defining algorithms for request handling, but the work to fully
> integrate that everywhere is still remaining. Much of it tightening up
> the language to make things more strictly defined. One thing that is
> totally lacking for example is integration with event loops, another
> is cursors.
>
> So the more help we can get, the bette

Re: [Widgets] and OAuth or other similar redirect-based protocols

[Scott Wilson]

Hi Bryan,

We've looked at this in Apache Wookie, which does use Widgets in a 
browser/webserver context. The general approach we've been discussing is 
similar to how Apache Shindig handles oAuth - to put the oAuth logic within the 
framework itself rather than in the Widget. So these issues around redirect and 
origin aren't a problem for the Widget but are instead part of how the Widget 
UA (aka Widget Runtime or WRT) implements oAuth. So oAuth would be a "feature" 
injected at runtime by the UA/WRT, and the Widget would have to access it via a 
JS API. These JS calls are then handled by the UA/WRT which has to handle the 
other "leg" of the oAuth call and render the authz screens presented for the 
user.

That said there are some issues around managing consumer secrets that are 
common to frameworks that we still have to address - as Widgets are portable 
and transparent you can't just encode the consumer secret in the widget's 
config.xml and distribute it on the web. Which means the framework has to 
manage them and request them for each Widget. Also, we don't have a standard 
for the JS API used for an oAuth feature; one option is to try to follow the 
same conventions as in OpenSocial[1] .

(If you're interested, there is a discussion on this topic on the wookie-dev 
list [2])

S 

[1] 
http://opensocial-resources.googlecode.com/svn/spec/1.1/Core-Gadget.xml#gadgets.oauth.Popup
[2]  http://www.mail-archive.com/wookie-...@incubator.apache.org/msg01922.html

On 1 Nov 2010, at 12:19, Bryan Sullivan wrote:

> Hi,
> Can anyone point to an example of how to use HTTP redirect-based protocols 
> such as OAuth with widgets? There seem to be issues with the use of these 
> protocols due to the difference between widgets and browser-based webapps, in 
> particular with the two aspects:
> widgets cannot access network resources unless an access request/dependency 
> to the domain is declared per the WARP spec. Thus any domain that is to be 
> used in a redirect-based protocol needs to be known up-front and explicitly 
> included per WARP.
> for widgets, there is no “origin” or at least “base” that can be used in a 
> redirect-based protocol. All that widgets could expose for redirect purposes 
> are relative URIs for their resources. Thus redirect protocols/designs in 
> which one widget page makes a request which is intended to result in a 
> redirect to another widget page, will not work.
> 
> An example of how to do this for widgets, e.g. a Twitter-enabled widget (as 
> Twitter uses OAuth) would be very helpful.
> 
> It does seem that applications using XHR for this (as compared to web 
> links/anchors etc) would/should be in total control of the operation of XHR, 
> but they would need to handle all HTTP requests and responses (including 
> redirects).
> 
> Apologies in advance if this request is not clear from a technical 
> perspective. 
> 
> Bryan



smime.p7s
Description: S/MIME cryptographic signature

Re: ACTION-591: Checkin updates for issues 150 and 151 (Web Applications Working Group)

[Marcos Caceres]

Hi,

below is an attempt to close ISSUE-150, ISSUE-151, ISSUE-152 (see [0], 
[1], [2] below).


On 10/21/10 3:22 PM, Web Applications Working Group Issue Tracker wrote:


ACTION-591: Checkin updates for issues 150 and 151 (Web Applications Working 
Group)

http://www.w3.org/2008/webapps/track/actions/591


ISSUE-150: Email and param name and value as 'Keyword attributes' is 
causing confusion in Widgets P&C Spec [0]


Added text:
==String attribute==
The value of a string attribute is any string that conforms to [XML] as 
a valid string for an XML attribute. The purpose of this attribute type 
is to classify strings that are not affected by the dir attribute, such 
as the email attribute.


Modified email attr, and param name and value attributes to use string 
attribute instead.


ISSUE-151: required invalid feature should be ignored.

Updated text:
If feature-name is not a valid IRI, and required-feature is false, then 
the user agent must ignore this element.


Test is here:
http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-ignore-unrequired-feature-with-invalid-name/000/

ISSUE-152

# lt
http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-klLDaEgJeU/004/

Tests support of XML, by making sure the user agent treats < as 
malformed XML. To pass, the user agent must treat this as an invalid 
widget.


# amp
http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-klLDaEgJeU/005/

Tests support of XML, by making sure the user agent treats & as 
malformed XML. To pass, the user agent must treat this as an invalid widget.


[0] http://www.w3.org/2008/webapps/track/issues/150
[1] http://www.w3.org/2008/webapps/track/issues/151
[2] http://www.w3.org/2008/webapps/track/issues/152

--
Marcos Caceres
Opera Software

Re: Comments on the http://www.w3.org/TR/widgets/

[Marcos Caceres]

Hi Viji,

Sorry for taking sooo long to respond... I've attempted to address
your feedback below.

For the "disposition of comments" for this specification, it is
important that you respond to this email with confirmation that you
are either satisfied or dissatisfied with the changes I have made.
The W3 process C requires the we attempt to record that the commenter
is satisfied with the changes.

On Tue, Oct 19, 2010 at 2:40 PM, viji  wrote:
> All
>
>  Here are some of the comments on http://www.w3.org/TR/widgets/ W3C Working
> Draft 5 October 2010
>
> 1. 7.9.2. The email Attribute
>
> mentions that email is a keyword attribute where
>
> A keyword is a string that is reserved for the purpose of this
> specification. The value of a keyword attribute is a keyword  that is one of
> a finite set specified in the attribute's definition in the case given in
> this specification.
>
> Does this mean that the finite set will be defined in the specification ? or
> the spec assumes that there will be a finite set based on the attributes
> definition in the specification.

No, sorry about the confusion. I used erroneously defined it as a
keyword attribute to stop the parsing algorithm from applying dir to
it. I have defined a new type of attribute which is simply a "string
attribute". The spec now reads:

[[
String attribute
The value of a string attribute is any string that conforms to [XML]
as a valid string for an XML attribute. The purpose of this attribute
type is to classify strings that are not affected by the dir
attribute, such as the email attribute (i.e., these attributes will
not treated as displayable strings during Step 7).
]]

I have updated the email attribute, as well as the param element's attributes.

> This would mean that the email attribute can only hold emails and not any
> other string ?

As above, it is now any string, so long as it does not break XML parsing rules.

> For param element's name and value attributes, how is the finite set defined
> ? Do we let the feature defined specify the set ?

As above. It is now any valid string so long as it does not break XML.

> 2. 9.1.9. Rule for Getting Text Content with Normalized White Space
>
>  In the example given, is the dir attribute for Dude ignored ?

No, dir is applied. Dude would be presented right-to-left. If it was
HTML, it would be marked up like this:

The Awesome Super  DudeWidget

> The sentence
> "The resulting widget name would be "The Awesome Super Dude Widget" but
> represented as a localizable string that retains" does not seem complete

I've removed "that retains". I've said: "(please note that "Dude" is
rendered right-to-left)"

> 3.  7.11. The icon  Element and its Attributes
>
>  Attributes:
>    Global attributes, src, width, height.
>
>  global attributes, xml.lang does not apply as mentioned in the spec.
>  dir also would not apply to icon element ?
>  Is Global attributes required as an attribute to icon element.
>
>  Same thing applies to content element, feature element, param element

i have added the following clarification to 7.5. Global Attributes:

"Although global attributes can be used on any element in this
specification, they sometimes have no effect on the element on which
they are used. For example, applying dir attribute on an icon element
will have no effect on the icon elements or any of its attributes.
What effect specifying a global attribute has on an elements is
determined by Step 7 of this specification."

Does that help?

-- 
Marcos Caceres
Opera Software ASA, http://www.opera.com/
http://datadriven.com.au

Re: Comment on Widget Interface...

[Marcos Caceres]

On Thu, Oct 14, 2010 at 5:58 PM, Phillips, Addison  wrote:
> Hello Art, Marcos, and Webapps,
>
> During our teleconference yesterday [1], I was tasked with formally replying 
> to this request on behalf of the Internationalization WG.
>
> I would still like to see the 'locale' field restored to the interface. It's 
> important to be able to query which locale the widget is running in 
> (especially in the face of upcoming ECMAScript internationalization changes) 
> so that the caller can match it if necessary.
>

IMHO, navigator.language is already there so we should just rely on
that. We should push HTML5 to standardize it.

> I agree with Marcos's approach to returning the @lang. Marcos concluded with 
> this comment:
>

I will add @lang to the Widget interface.

>> >
>> > 3. At runtime, upon getting an attribute from the Widget object
>> (e.g.,
>> > widget.name), you need to display that properly. The case is:
>> >
>> > $("#somePElement).innerHTML = widget.name; //in Arabic
>> >
>> > To display it properly, we need something like the algorithm
>> described in:
>> > http://www.iamcal.com/understanding-bidirectional-text/
>
> Most user-agents have implemented the Unicode Bidirectional Algorithm (which 
> is what Cal is describing), so that isn't the issue, so much as the fact that 
> sometimes the algorithm needs a little help. The problem is that the base 
> direction of a string is sometimes necessary to get the correct behavior from 
> strings.
>
> For excellent illustrations of this, see [2].
>
> Using Unicode Bidi control characters is one way to manage this, but in a 
> markup context, the 'dir' attribute is really preferable. If you're going to 
> create LocalizedString, it should have both a lang and dir attribute that can 
> be queried. Having @dir in P&C will help the Widget engine display the string 
> properly too.
>
> I look forward to seeing the resulting spec published. Please let me know if 
> you need any assistance from me in making progress.
>
> Thanks,
>
> Addison
>
> [1] http://www.w3.org/2010/10/13-i18n-minutes.html
> [2] http://www.w3.org/International/articles/inline-bidi-markup/
>
> Addison Phillips
> Globalization Architect (Lab126)
> Chair (W3C I18N, IETF IRI WGs)
>
> Internationalization is not a feature.
> It is an architecture.
>
>



-- 
Marcos Caceres
Opera Software ASA, http://www.opera.com/
http://datadriven.com.au

Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

[Olli Pettay]

On 10/30/2010 09:34 AM, Jonas Sicking wrote:

On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky  wrote:

On 10/28/10 11:29 PM, Jonas Sicking wrote:


Personally I like the proposed responseType solution.


The one where you pick one up front and it throws if you ask for something
else, right?


I agree that it has a downside in that it doesn't allow figuring out
the type as data starts coming in.


Well, that, and the whole "throws exceptions" bit...


I'm not entirely following what your concern is. I.e. what usage
pattern you are worried will either break in existing code, or people
will get wrong in new code.

My suggestion is that we add a .response property which always contain
the result, no matter what type is being fetched. In the "default"
mode, when .resonseType is not set, it can contain the same value as
.responseText currently contains. If .responseType is set to "blob" it
will return a Blob object, if it's set to "binary" it will return a
ArrayBuffer etc.


But the existing responseText and responseXML would still work as they
work atm? They would be basically the old, sort-of-deprecated-API?
If developer wants to get stringified value from ArrayBuffer response,
she/he could use .responseText?

(Browsers could actually warn in the error console if use of old and
new API is mixed)


-Olli

Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

[Chris Marrin]

On Nov 1, 2010, at 12:47 PM, Olli Pettay wrote:

> On 10/30/2010 09:34 AM, Jonas Sicking wrote:
>> On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky  wrote:
>>> On 10/28/10 11:29 PM, Jonas Sicking wrote:
 
 Personally I like the proposed responseType solution.
>>> 
>>> The one where you pick one up front and it throws if you ask for something
>>> else, right?
>>> 
 I agree that it has a downside in that it doesn't allow figuring out
 the type as data starts coming in.
>>> 
>>> Well, that, and the whole "throws exceptions" bit...
>> 
>> I'm not entirely following what your concern is. I.e. what usage
>> pattern you are worried will either break in existing code, or people
>> will get wrong in new code.
>> 
>> My suggestion is that we add a .response property which always contain
>> the result, no matter what type is being fetched. In the "default"
>> mode, when .resonseType is not set, it can contain the same value as
>> .responseText currently contains. If .responseType is set to "blob" it
>> will return a Blob object, if it's set to "binary" it will return a
>> ArrayBuffer etc.
> 
> But the existing responseText and responseXML would still work as they
> work atm? They would be basically the old, sort-of-deprecated-API?
> If developer wants to get stringified value from ArrayBuffer response,
> she/he could use .responseText?
> 
> (Browsers could actually warn in the error console if use of old and
> new API is mixed)

I think we could go one step further and throw if the author used responseText 
or responseXML and then tried to use responseObject or responseType, and vice 
versa. Doing so would steer authors into the modern APIs and would make the 
implementor's job easier.

-
~Chris
cmar...@apple.com

Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

[Olli Pettay]

On 11/01/2010 08:57 PM, Chris Marrin wrote:


On Nov 1, 2010, at 12:47 PM, Olli Pettay wrote:


On 10/30/2010 09:34 AM, Jonas Sicking wrote:

On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky
wrote:

On 10/28/10 11:29 PM, Jonas Sicking wrote:


Personally I like the proposed responseType solution.


The one where you pick one up front and it throws if you ask
for something else, right?


I agree that it has a downside in that it doesn't allow
figuring out the type as data starts coming in.


Well, that, and the whole "throws exceptions" bit...


I'm not entirely following what your concern is. I.e. what usage
pattern you are worried will either break in existing code, or
people will get wrong in new code.

My suggestion is that we add a .response property which always
contain the result, no matter what type is being fetched. In the
"default" mode, when .resonseType is not set, it can contain the
same value as .responseText currently contains. If .responseType
is set to "blob" it will return a Blob object, if it's set to
"binary" it will return a ArrayBuffer etc.


But the existing responseText and responseXML would still work as
they work atm? They would be basically the old,
sort-of-deprecated-API? If developer wants to get stringified value
from ArrayBuffer response, she/he could use .responseText?

(Browsers could actually warn in the error console if use of old
and new API is mixed)


I think we could go one step further and throw if the author used
responseText or responseXML and then tried to use responseObject or
responseType, and vice versa. Doing so would steer authors into the
modern APIs and would make the implementor's job easier.


I doubt throwing an exception would make implementor's job
significantly easier. And based on my experience in
deprecating some event handling related methods, posting
warnings about deprecated API to error console is
surprisingly effective.



-Olli

Re: [IndexedDB] IDBKeyRange cleanup

[Jonas Sicking]

On Monday, November 1, 2010, Jeremy Orlow  wrote:
> On Sat, Oct 30, 2010 at 12:24 AM, Jonas Sicking  wrote:
>
>
> On Sun, Oct 24, 2010 at 8:06 AM, Jeremy Orlow  wrote:
>> On Sat, Oct 23, 2010 at 2:45 AM, Jonas Sicking  wrote:
>>>
>>> Hi all,
>>>
>>> IDBKeyRange is in need of some cleanup. The first issue is its
>>> constructors. Currently the IDL for IDBKeyRange, define that the
>>> constructors, .only, .leftBound, .rightBound, .bound, on object
>>> instances themselves. I don't think this is intentional since first of
>>> all it makes it impossible to create the first IDBKeyRange, second,
>>> second it seems strange to have constructor functions on instances.
>>>
>>> It seems like the intent is that the following should work:
>>>
>>> x = new IDBKeyRange.bound(...);
>>> and possibly also
>>> x = IDBKeyRange.bound(...);
>>> (the latter works for for example XMLHttpRequest, JS-heads have also
>>> informed me that it should work).
>>
>> The latter is what we do in Chromium and what I'm pretty sure we agreed upon
>> in earlier threads.  Since these methods are factories, it seems as though
>> the new operator should not be necessary.
>>
>>>
>>> Unfortunately there is no way to express this in WebIDL, so I think we
>>> need to describe it in prose instead. I'll raise this with Cameron,
>>> but I think that since at this point only IndexedDB uses these
>>> "static" functions, it might not make sense to add support to WebIDL.
>>
>> I believe "class methods" is the more accepted term for such methods.  I'd
>> rather we look at adding these to WebIDL now rather than waiting for the
>> next instance that uses them as I'd hope we didn't add a new concept just
>> for one interface in one API.  Prose seems like the right solution in the
>> mean time though.
>>
>>>
>>> The other thing is that the .flags attribute is really not very
>>> javascript friendly as it uses bitfields. It also is weird in that it
>>> has multiple bits, but some have strong interdependencies. For example
>>> if SINGLE is set LEFT_OPEN and RIGHT_OPEN must be false, and
>>> LEFT_BOUND and RIGHT_BOUND must be true. It also seems like the
>>> LEFT_BOUND flag is closely correlated to the .left property.
>>>
>>> I suggest the following API instead:
>>>
>>> interface IDBKeyRange {
>>>  readonly attribute any left;
>>>  readonly attribute any right;
>>>  readonly attribute boolean leftOpen;
>>>  readonly attribute boolean rightOpen;
>>> };
>>>
>>> the .left and .right properties return 'null' or 'undefined' (to be
>>> discussed) when the keyrange isn't bound in that direction.
>>
>> I agree the flags attribute is confusing and not very JavaScript like.  I
>> also like your solution.  null is probably what it should return when not
>> bounded.
>
> Why did you end up using undefined rather than null?  "The key range 
> lower value is 
> undefined or less than key value."

null is actually currently defined as a valid key, so we can't use it
to signal an absence of key. Though that's something I want to change.
(part of the whole keyPath-for-indexes discussion).

However undefined also feels more javascripy to show that something is
missing or not defined :)

>> What should the open param return if its associated left/right is not bound?
>>  I don't care much, but it should definitely be specced.
>>>
>>> Another question I had is if "left" and "right" really are good names.
>>> Seems to me that "upper" and "lower" are better words, but it might be
>>> that left/right is established concepts in the database community? I
>>> don't feel strongly on this issue. Oh, I see now that bug 10397 is
>>> filed on this exact issue.
>>
>> Yup.  Agree that left/right are bad names.
>> The fact that we're discussing things over again points to the fact that we
>> really need to get on top of all the bugs against the spec.  Most of them
>> should be pretty easy.  Will the editors have time to address these before
>> TPAC?  If not, does anyone have a problem with me becoming an editor?
>>
>>>
>>> Lastly, should we allow values to be passed directly to all APIs that
>>> currently take IDBKeyRanges? It seems nice to not require people to
>>> create an IDBKeyRange object using patterns like:
>>>
>>> req = objectStore.openCursor(new IDBKeyRange.only(foo));
>>>
>>> and instead allow
>>>
>>> req = objectStore.openCursor(foo);
>>
>> I'm OK with this.
>>
>>>
>>> Similarly, should we allow IDBObjectStore.get on and IDBIndex.get to
>>> take a IDBKeyRange and return the first value that matches the
>>> keyrange. This would allow things like "give me the first entry with a
>>> value greater than X".
>>
>> That seems like it could be valuable.  I'd support such a change.
>
> I've implemented these changes in
> http://dvcs.w3.org/hg/IndexedDB/rev/e5a08025e518
>
> There is definitely a lot of work remaining on the spec. I've added a
> lot of infrastructure which should make this *much* easier, such as
> defining algorithms for request handling, but the work to fully
> integrate that everyw

Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

[Jonas Sicking]

On Monday, November 1, 2010, Olli Pettay  wrote:
> On 10/30/2010 09:34 AM, Jonas Sicking wrote:
>
> On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky  wrote:
>
> On 10/28/10 11:29 PM, Jonas Sicking wrote:
>
>
> Personally I like the proposed responseType solution.
>
>
> The one where you pick one up front and it throws if you ask for something
> else, right?
>
>
> I agree that it has a downside in that it doesn't allow figuring out
> the type as data starts coming in.
>
>
> Well, that, and the whole "throws exceptions" bit...
>
>
> I'm not entirely following what your concern is. I.e. what usage
> pattern you are worried will either break in existing code, or people
> will get wrong in new code.
>
> My suggestion is that we add a .response property which always contain
> the result, no matter what type is being fetched. In the "default"
> mode, when .resonseType is not set, it can contain the same value as
> .responseText currently contains. If .responseType is set to "blob" it
> will return a Blob object, if it's set to "binary" it will return a
> ArrayBuffer etc.
>
>
> But the existing responseText and responseXML would still work as they
> work atm? They would be basically the old, sort-of-deprecated-API?
> If developer wants to get stringified value from ArrayBuffer response,
> she/he could use .responseText?

They would work as-is is responseType is the empty string (i.e.
default). If .responseType is set to anything else they throw an
exception.

> (Browsers could actually warn in the error console if use of old and
> new API is mixed)

That would probably be a good idea too.

/ Jonas

Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

[Jonas Sicking]

On Monday, November 1, 2010, Olli Pettay  wrote:
> On 10/30/2010 09:34 AM, Jonas Sicking wrote:
>
> On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky  wrote:
>
> On 10/28/10 11:29 PM, Jonas Sicking wrote:
>
>
> Personally I like the proposed responseType solution.
>
>
> The one where you pick one up front and it throws if you ask for something
> else, right?
>
>
> I agree that it has a downside in that it doesn't allow figuring out
> the type as data starts coming in.
>
>
> Well, that, and the whole "throws exceptions" bit...
>
>
> I'm not entirely following what your concern is. I.e. what usage
> pattern you are worried will either break in existing code, or people
> will get wrong in new code.
>
> My suggestion is that we add a .response property which always contain
> the result, no matter what type is being fetched. In the "default"
> mode, when .resonseType is not set, it can contain the same value as
> .responseText currently contains. If .responseType is set to "blob" it
> will return a Blob object, if it's set to "binary" it will return a
> ArrayBuffer etc.
>
>
> But the existing responseText and responseXML would still work as they
> work atm? They would be basically the old, sort-of-deprecated-API?
> If developer wants to get stringified value from ArrayBuffer response,
> she/he could use .responseText?

They would work as-is is responseType is the empty string (i.e.
default). If .responseType is set to anything else they throw an
exception.

> (Browsers could actually warn in the error console if use of old and
> new API is mixed)

That would probably be a good idea too.

/ Jonas

Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

[Boris Zbarsky]

On 10/30/10 3:34 AM, Jonas Sicking wrote:

I'm not entirely following what your concern is. I.e. what usage
pattern you are worried will either break in existing code, or people
will get wrong in new code.


Well, one simple usage pattern is using the jquery "get me some stuff" 
API and then trying to get something other than responseText or 
responseXML off the resulting XHR.



Like maciej showed, if we expose multiple properties which at the same
time contain the result data in different formats, it's very easy to
accidentally use more memory than needed. For example by checking
progress by measuring .responseText.length, or by checking what type
was returned by poking at the various properties until finding one
that works.


Fair.  That last problem I had not thought of.


I say by making it possible to choose if you want streaming or
give-me-the-full-result-once-all-of-it-is-downloaded behavior. If need
be before the request is started.


The problem is that it seems to be somewhat common for the request 
starter and the data consumer to be different entities (and for there to 
be more than one data consumer).



That seems like an implementation detail.  Nothing is really preventing
segmented storage of the data (not even the responseArrayBuffer getter, if
it were added).


Indeed, though at some point the implementation likely will have to
flatten the data in order to not have to support fragmented
strings/arraybuffers throughout the JS engine.


Sure.


As long as only one entity is doing the expecting, right?  Right now jquery
expects to get responseText, so if you expect something else you can't use
jquery's XHR wrappers, say


I'm not terribly worried about library wrappers. My money is on
libraries updating faster than browsers are releasing implementations.


My money is on jquery tip getting updated faster than browsers release 
implementations.


My money is on browsers releasing implementations way faster than 
websites are updated to a newer jquery version.


That, at least, has been our experience with libraries in the past... 
The last time jquery made a bogus assumption and then fixed it several 
months before a release of ours that would cause breakage due to that 
assumption it took heroic efforts over a course of many months by a 
whole team of people just to get the top several dozen sites being 
bitten by the bug to update.



I've assumed that all proposals made so far maintain full backwards
compatibility. So I'm not terribly worried about existing content. Old
browsers will hold people back much more than old JS libraries.


I think you're being way too optimistic; see above.

-Boris

[Bug 11190] New: Make scripts created by createContextualFragment() executable

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11190

   Summary: Make scripts created by createContextualFragment()
executable
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: ASSIGNED
  Severity: normal
  Priority: P1
 Component: DOM Range
AssignedTo: ms2...@gmail.com
ReportedBy: ms2...@gmail.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


See  for reference.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

RE: IndexedDB TPAC agenda

[Pablo Castro]

A few other items to add to the list to discuss tomorrow:

- Blobs support: have we discussed explicitly how things work when an object 
has a blob (file, array, etc.) as one of its properties?
- Close on collation and international support
- How do applications request that they need more storage? And related to this, 
at some point we discussed temporary vs permanent stores. Close on the whole 
story of how space is managed.
- Database-wide exception handlers

Looking forward to the discussion tomorrow.

-pablo


From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Jeremy Orlow
Sent: Monday, November 01, 2010 1:34 PM
To: Jonas Sicking
Cc: public-webapps@w3.org
Subject: Re: IndexedDB TPAC agenda

On Mon, Nov 1, 2010 at 12:23 PM, Jonas Sicking  wrote:
On Mon, Nov 1, 2010 at 5:13 AM, Jeremy Orlow  wrote:
> On Mon, Nov 1, 2010 at 11:53 AM, Jonas Sicking  wrote:
>>
>> On Mon, Nov 1, 2010 at 4:40 AM, Jeremy Orlow  wrote:
>> > What items should we try to cover during the f2f?
>> > On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking  wrote:
>> >>
>> >> > P.S. I'm happy to discuss all of this f2f tomorrow rather than over
>> >> > email
>> >> > now.
>> >>
>> >> Speaking of which, would be great to have an agenda. Some of the
>> >> bigger items are:
>> >>
>> >> * Dynamic transactions
>> >> * Arrays-as-keys
>> >> * Arrays and indexes (what to do if the keyPath for an index evaluates
>> >> to an array)
>> >> * Synchronous API
>> >
>> > * Compound keys.
>> > * What should be allowed in a keyPath.
>>
>> Aren't "compound keys" same as "arrays-as-keys"?
>
> Sorry, I meant to say compound indexes.
> We've talked about using indexes in many different ways--including compound
> indexes and allowing keys to include indexes.  I assumed you meant the
> latter?
I'm lost as to what you're saying here. Could you elaborate? Are you
saying "index" when you mean "array" anywhere?

oops.  Yes, I meant to say: "We've talked about using arrays in many different 
ways--including compound indexes and allowing keys to include arrays.  I 
assumed you meant the latter?"
 
>> * What should happen if an index's keyPath points to a property which
>> doesn't exist or which isn't a valid key-value? (same general topic as
>> "arrays and indexes" above)
>
> We've talked about this several times.  It'd be great to settle on something
> once and for all.
Agreed.

>> * What happens if the user leaves a page in the middle of a
>> transaction? (this might be nice to tackle since there'll be lots of
>> relevant people in the room)
>
> I'm pretty sure this is simple: if there's an onsuccess/onerror handler that
> has not yet fired (or we're in the middle of firing), then you abort the
> transaction.  If not, the behavior is undefined (because there's no way the
> app could have observed the difference anyway).  The aborting behavior is
> necessary since the user could have planned to execute additional commands
> atomically in the handler.
There is also the option to let the transaction finish. They should be
short-lived so it shouldn't be too bad.

I.e. keep the page alive for a bit longer in the background or something that 
blocks page unload?  Is there precedent for this elsewhere?  This sounds pretty 
complicated to get right both in terms of implementation and speccing.  Let's 
chat about it though.
 
>> * Error handling
>
> What do you mean by this?
How to handle exceptions in various places. Where (error) events
propagate. How does it relate to window.onerror. What happens if you
do/don't call preventDefault on the error event?


Sounds good.

Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

[Chris Marrin]

On Nov 1, 2010, at 1:06 PM, Olli Pettay wrote:

>>> ...But the existing responseText and responseXML would still work as
>>> they work atm? They would be basically the old,
>>> sort-of-deprecated-API? If developer wants to get stringified value
>>> from ArrayBuffer response, she/he could use .responseText?
>>> 
>>> (Browsers could actually warn in the error console if use of old
>>> and new API is mixed)
>> 
>> I think we could go one step further and throw if the author used
>> responseText or responseXML and then tried to use responseObject or
>> responseType, and vice versa. Doing so would steer authors into the
>> modern APIs and would make the implementor's job easier.
> 
> I doubt throwing an exception would make implementor's job
> significantly easier. And based on my experience in
> deprecating some event handling related methods, posting
> warnings about deprecated API to error console is
> surprisingly effective.

I think they would make the implementation simpler because you wouldn't have to 
worry about the case of keeping around multiple versions of the data just in 
case the author tries to use multiple mechanisms. Adding new access mechanisms 
can get very cumbersome if you have to support every permutation. This might 
avoid that.

-
~Chris
cmar...@apple.com

Re: Questions about API Design, composability and multiple arguments

[Cameron McCormack]

Hi Nathan.

I can give you some off-the-cuff personal opinions on the questions you
ask.

Nathan:
> interface Store {
> readonly attribute unsigned long length;
> 
> T  get (in unsigned long index);
> void   add (in T t);
> void   merge(in Store store);
> sequencetoArray();
> 
> Store  filter (in TFilter filter);
> void   forEach (in TCallback callback);
> 
> };
> 
> 
> (1) Adding multiple items
> What's the best approach to allow adding multiple items?
> 
> - add(in T[] t)
> would this allow a single T not in an array to be passed in?
> can one define a function with WebIDL so that it accepts either a
> single item of type T or an array of T?

It wouldn’t allow this.  But you could overload to allow this:

  void add(in T t);
  void add(in sequence ts);

> - add(in T... t)
> is the variadic approach better?
> also if at least one argument is required would the IDL have to be:
>   add(in T t, in T... ts) ?

The reason I don’t prefer variadic functions like this is that it makes
it more complicated to call if you already have an array of items built
up that you want to pass in.

  var ts = getItemsToAdd();
  store.add.apply(store, ts);

On the other hand, many built-in Array methods use the variadic
approach.

> - addAll(??)
> Would it be preferable to introduce an addAll function?
> If so, then the above two approaches also apply here, which one?

If the question is whether to use a different name rather than overload
‘add’, I don’t have much of an opinion.

> Also you'll note the toArray() method, if the advice above is to the
> above is to take the variadic approach, then how should one address
> importing an array - and further would the appropriate type for such
> an argument be sequence or T[]? `addArray (in ?? t)`

If it’s just used an operation argument, then it won’t matter either
way.  If an Array is passed to an operation expecting a sequence,
then a reference to that Array won’t be kept by the object (nor will it
modify the Array).  The array type T[] is best used if you want to have
an array that both user JS code and the DOM objects can keep a hold of
and modify.

> (2) Chaining by return
> Should the method add(in T t) return Store, the current store to
> which the T has just been added so as to allow chaining as such:
>store.add(t1).add(t2).add(t3)

I’m not a big fan of that kind pattern.  Some are, though.  It obviously
breaks as soon as you want to return a meaningful value from the method.

> Likewise the same question can be asked about merge()? - however
> this adds in a twist because filter() will not modify the contents
> of the store and return a new Store (it acts like Store is
> immutable), whereas merge would modify the contents of the store and
> then return itself.
> 
> Likewise again with forEach?

Right, you would have to judge when it makes sense to return the Store
and when not to.  User of the API would then have to be aware of when
they can chain method calls and when they can’t.

> (3) merge()
> Where merge(in Store store) is a method which adds non duplicated
> members of the store passed in to the current store, would this be
> better named 'import' or something else?

No opinion.

> Would it be wise to add a counterpart method which treated the store
> as immutable returning a new store (as filter does)?

Maybe!

> (4) counterpart methods
> Finally, just a quick one, is it worth considering adding
> counterpart methods for composability, as in given we have
> Store.add(T t) would it also be wise to include a method
> T.addTo(Store store) - and if so should it return the instance of T
> or the Store with t added?

Those kinds of methods *could* be handy for higher order functions, I
suppose.  Although in this specific case, it seems like you’d be more
likely to have an array of T objects rather than an array of Stores.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: [IndexedDB] IDBKeyRange cleanup

[Cameron McCormack]

Jonas Sicking:
> Unfortunately there is no way to express this in WebIDL, so I think we
> need to describe it in prose instead. I'll raise this with Cameron,
> but I think that since at this point only IndexedDB uses these
> "static" functions, it might not make sense to add support to WebIDL.

I think it makes sense enough to add support for static operations, so
I’ve added it:

  http://dev.w3.org/2006/webapi/WebIDL/#idl-operations
  http://dev.w3.org/2006/webapi/WebIDL/#idl-static-operations
  http://dev.w3.org/2006/webapi/WebIDL/#es-operations
  http://dev.w3.org/2006/webapi/WebIDL/#proddef-Qualifiers

-- 
Cameron McCormack ≝ http://mcc.id.au/