[Bug 10058] New: Specify order for indexes which contain duplicate key values

[bugzilla]

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

   Summary: Specify order for indexes which contain duplicate key
values
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: nikunj.me...@oracle.com
ReportedBy: jo...@sicking.cc
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Consider an objectStore, with keyPath "id", containing the following objects:

{ id: 1, name: "foo", flags: ["hi", "low"] }
{ id: 2, name: "foo", flags: ["apple", "orange"] }
{ id: 3, name: "goo", flags: ["fahrvergnügen"] }

And an index keyed on the "name" property. What should the following code
alert?

results = [];
db.objectStore("myObjectStore").index("nameIndex").openCursor().onsuccess =
function(e) {
 cursor = e.result;
 if (!cursor) {
   alert(results);
 }
 results.push(cursor.value);
 cursor.continue();
};

Possible imaginable results are:
"1,2,3"
"2,1,3"

In order to keep results consistent and predictable we should define that one
of these results are correct, and define which one that is. I would recommend
that indexes with duplicate values should be defined to be ordered by the key
order in the objectStore. I.e. in this case "1,2,3" would be defined as the
correct result.

-- 
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: any plans to move from cvs to git?

[Masataka Yakura]

On Sun, Jun 27, 2010 at 12:52 PM, Matt Di Pasquale
 wrote:
> github rules!
>

I guess not. But they recently started offering a Mercurial-powered
dvcs platform.



hth,
-- 
Masataka Yakura

Re: [IndexedDB] .value of no-duplicate cursors

[Jeremy Orlow]

On Thu, Jul 1, 2010 at 12:07 PM, Jonas Sicking  wrote:

> Hi All,
>
> This was one issue we ran into while implementing IndexedDB. In the
> code examples I'll use the mozilla proposed asynchronous APIs, but the
> issue applies equally to the spec as it is now, as well as the
> synchronous APIs.
>
> Consider an objectStore containing the following objects:
>
> { id: 1, name: "foo", flags: ["hi", "low"] }
> { id: 2, name: "foo", flags: ["apple", "orange"] }
> { id: 3, name: "foo", flags: ["hello", "world"] }
> { id: 4, name: "bar", flags: ["fahrvergnügen"] }
>
> And an index keyed on the "name" property. What should the following code
> alert?
>
> results = [];
> db.objectStore("myObjectStore").index("nameIndex").openCursor(null,
> IDBCursor.NEXT_NO_DUPLICATE).onsuccess = function(e) {
>  cursor = e.result;
>  if (!cursor) {
>alert(results.length);
>alert(results);
>  }
>  results.push(cursor.value);
>  cursor.continue();
> };
>
> It's clear that the first alert would display '2', as there are 2
> distinct 'name' values in the objectStore. However it's not clear what
> the second alert would show. I.e. what would cursor.value be on each
> 'success' event firing?
>
> We could define that it is one of the rows matching the distinct
> value. In that case either "1,4", "2,4" or "3,4" would be valid values
> for the second alert. If we choose that solution then ideally we
> should define which one and make it consistent in all implementations.
>
> Alternatively we could say that .value is null for all *_NO_DUPLICATE
> cursors.
>
> The question equally applies if the above code used openObjectCursor
> rather than openCursor. However if we define that .value is null for
> *_NO_DUPLICATE cursors, then openObjectCursor with *_NO_DUPLICATE
> doesn't make much sense in that it returns the same thing as
> openCursor with *_NO_DUPLICATE.
>
> I don't personally don't care much which solution we use. I'm unclear
> on what the exact use cases are for *_NO_DUPLICATE cursors.


This is a very good point.  What are the use cases?  After all, you can
easily emulate such a cursor yourself.  Unless there are some compelling use
cases, I'd be happy to just get rid of it.


> However if
> we do say that .value should represent a particular row, then I think
> we should define which row is returned.
>

Agreed that it should be deterministic.  I'm fine with null, the first
value, or the last value.  If we do null, then I think calling
openObjectCursor with *_NO_DUPLICATE should be an error.  It seems like
there'd be some value in returning the first or last value, though since an
app might know that all entries in some particular object store with some
particular key will share some other property in common.  (Of course, in
this case, it'd probably be better for the application to normalize the data
into multiple objectStores, but given that joins will be a pain and doing so
might be overkill, it still seems like a use case worth supporting.
 Especially since it's little additional effort on our part.)  If it's
between first and last, I'd just as soon say that we return the first value
associated with each key.  ...assuming we don't just get rid of this feature
for v1.

J

Re: [IndexedDB] Should .add/.put/.update throw when called in read-only transaction?

[Jeremy Orlow]

I've thought about this more and have some additional doubts inline.

On Thu, Jul 1, 2010 at 11:55 AM, Jonas Sicking  wrote:

> On Wed, Jun 30, 2010 at 6:42 PM, Jeremy Orlow  wrote:
> > On Thu, Jul 1, 2010 at 11:17 AM, Jonas Sicking  wrote:
> >>
> >> Hi All,
> >>
> >> Currently the IndexedDB specification is silent on what should happen
> >> if IDBObjectStore.add, IDBObjectStore.put, IDBObjectStore.remove,
> >> IDBCursor.update or IDBCursor.remove() is called from a READ_ONLY
> >> transaction. There are two possible ways we can handle this:
> >>
> >> 1. We can throw an exception.
> >> 2. We can return a IDBRequest object and asynchronously fire a 'error'
> >> event on this object.
> >>
> >> The advantage of 1 is that we pretty much know that this was an error
> >> due to a bug in the web page,
>

I don't see why this is compelling.  Many of the other errors that you still
propose we fire via the callback are due to bugs in the page.


> >> and we can always know this
> >> synchronously without having to consult the database.
>

So?  Just because we can doesn't mean we should.


> >> Throwing an
> >> error means that all the existing infrastructure for error handling
> >> with automatically kick in. For example any higher-level try/catch
> >> constructs will have an opportunity to catch the error.
> >> Implementations generally report uncaught exceptions to an error log.
> >> The browser will fire an 'error' event on the window which the page
> >> can use for further logging. Firing an error event on the other hand
> >> does not allow the browser to automatically log the error in a console
> >> as the page hasn't yet gotten a chance to handle it.
>

Sure, but this doesn't help the majority of error conditions in IndexedDB.
 It also ignores the cost of handling errors in 2 different ways.


> >> The advantage of 2 is that this is consistent with other error
> >> conditions, such as writing duplicate keys, disk errors during writing
> >> the database to disk, internal errors in the database, etc.
>

The other problem is that users then need 2 sets of error handling routines
for each call.  Given how difficult it is to get web developers to do any
error checking, requiring 2 types of checks seems like a big downside.


> >> While consistency, and only needing to check for errors one way, is
> >> certainly good arguments, I would argue that people won't need to
> >> check for calling-add-on-read-only-transactions. For properly written
> >> code it's not an error that will occur, and thus there is no need to
> >> check for it. In fact, you probably are generally better off letting
> >> the exception bubble all the way up and get logged or caught by
> >> generic error handlers.
>

These are awfully bold assumptions.  Simply not catching the error is not an
option for many web applications or libraries.  At very least, they'll need
to add finally statements to handle such cases.

>> Additionally, the structured clone algorithm, which defines that an
> >> exception should synchronously be thrown if the object is malformed,
> >> for example if it consists of a cyclic graph. So .add/.put/.update can
> >> already throw under certain circumstances.
> >>
> >> Also compare to if we were using a different API strategy of making
> >> objectStores and cursors returned from READ_ONLY transactions not have
> >> mutating functions. In this case if someone tried to call .put(), that
> >> also would result in a exception from the JS interpreter stating that
> >> you're calling a function that doesn't exist.
> >>
> >> So I would argue that we should throw for at least all transaction
> >> violations. I.e. whenever you try to perform an action not allowed by
> >> the current transaction. This would also cover the case of calling
> >> createObjectStore/removeObjectStore/createIndex/removeIndex during a
> >> non-setVersion-transaction.
> >>
> >>
> >> There is also another case where synchronously know that an error will
> >> be reported. We could throw when IDBCursor.update() is called when the
> >> underlying object store uses in-line keys and the property at the key
> >> path does not match the key in this cursor's position. In this case we
> >> similarly immediately know that there is an error without having to
> >> consult the database. We also generally can be sure that there is a
> >> bug in the web page which would benefit from being reported like other
> >> bugs are.
> >>
> >> And like stated above, IDBCursor.update() can already throw if the
> >> passed in object can't be structurally cloned.
> >>
> >>
> >> Jeremy previously asked if there was a test we could use to
> >> clearly/intuitively break error conditions into two groups. Ones that
> >> cause exceptions to be thrown, and ones that cause error events to be
> >> fired. I would say that errors that do not depend on what data is in
> >> the database, but rather are clearly due to errors at the call site
> >> should throw an exception.
> >
> > This would limit us in the 

LCWD comments

[Krzysztof Maczyński]

Dear WebApps WG,

In this message I state my LC comments on the following documents:
[a] http://www.w3.org/TR/2009/WD-eventsource-20091222/
[b] http://www.w3.org/TR/2009/WD-webstorage-20091222/
[c] http://www.w3.org/TR/2009/WD-workers-20091222/

Some comments on particular drafts apply to those listed later above as well.

0. In [a]:
> The W3C Web Apps Working Group
It's either "WebApps" or "Web Applications" according to the charter.

1. [a] references HTML5 which is unlikely to go to Rec any time soon. What path 
do you envision following to resolve this? In particular, do you agree that 
these bits are generic, not specific to HTML, and therefore should be in 
separate specs and become Recs sooner (possibly at first with only a subset of 
what's currently in the HTML5 draft, given the possibility of multiple 
reiterations)? (Reminder: charters of our groups call explicitly for aligning 
such issues.)

2. In [a]:
> HTTP 302 Found, 303 See Other, and 307 Temporary Redirect responses must 
> cause the user agent to connect to the new server-specified URL, but if the 
> user agent needs to again request the resource at a later point, it must 
> return to the previously specified URL for this event source.
Does it include only requesting a representation of the resource using the same 
EventSource object, the same browsing context, or globally (as long as the UA 
remembers having requested it before)? Is this consistent (especially for 303) 
with HTTP semantics?

3. In [a]:
> Any other HTTP response code not listed here, and any network error that 
> prevents the HTTP connection from being established in the first place (e.g. 
> DNS errors), must cause the user agent to fail the connection.
I'm unsure whether it doesn't violate semantics of some HTTP codes already 
defined. But it surely imposes limits on what future codes may indicate, flying 
in the face of this extensibility point. All that this spec should say about 
the potentially coming unknown is that semantics of other codes must be applied 
as required for them.

4. text/event-stream uses text before / which is inappropriate and should be 
application. Entities of type text must be, at least as the last resort, 
feasible for rendering to the user as text (which not any sequence of octets 
is, e.g. text/html, but application/msword).

5. In [a]:
> formats of event framing defined by other applicable specifications may be 
> supported
What is event framing? Additionally, are we going to have „other applicable 
specifications” extension point everywhere? For the moment it's just a beast 
dwelling in the HTML5 spec, tolerated until it gets its extensibility story 
straight, but if it's going to affect other specs in this way, the TAG should 
certainly have a look.

6. Section 10 of [a] seems something new in W3C's LCs. What is the story behind 
specifying requirements on finalization (note that this name is better, since 
"garbage collection" looks like limiting this behaviour to environments with a 
GC) and some rules stating when a spec should include them? Has there been any 
architectural discussion about it?

7. In [b]:
> The term "JavaScript" is used to refer to ECMA262, rather than the official 
> term ECMAScript, since the term JavaScript is more widely known.
The term "JavaScript" already refers to a proprietary implementation of 
ECMAScript. A confusion should not be entrenched further just because it's 
common. Clarity will be appreciated by intended readers of the spec, of whom 
knowledge of this distinction can be safely assumed. The term is unused anyway.

8. In [b]:
> To mitigate this, pages can use SSL.
Please change to TLS which is the standard name.

9. [b] states more precise requirements on scripts running in the context of an 
HTMLDocument than otherwise. Should some of them apply more widely?

10. In [c]:
> the MIME type of the script is ignored
This is a new spec. It shouldn't be plagued with such idiosyncratic legacy 
mechanisms.

11. In [c]:
> there is no way to override the type. It's always assumed to be JavaScript.
This is a violation of orthogonality for no real benefit.

12. In [c]:
> If there are any outstanding transactions that have callbacks
What's a transaction, when has it got a callback?

13. Why does [c] define ErrorEvent instead of reusing DOMError? Besides, it 
uses a misnamed attribute "filename" and suboptimally spelled "lineno".

14. In [c]:
> Thus, scripts must be external files with the same scheme as the original 
> page: you can't load a script from a data: URL
Why impose this restriction? Is it that exceptions to same-origin policy when 
it's still new would be confusing for specifiers and the audience, so this 
possibility is postponed to the next version? In any case, I suggest allowing 
workers to be instantiated with Function objects (whatever this may be in 
language bindings, given positive resolution of 11) as well. Including workers 
directly inline seems natural in many scenarios.

15. Why using 

Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

[Brett Zamir]

On 6/29/10 2:36 PM, Chris Wilson wrote:
See, this is exactly why we asked the question - because it seems 
that behavior is inconsistent, we're not sure what the expectation is.


Note that the Firefox behavior I described is irrelevant to 
specification efforts, because it's not visible to web pages


I would really like to know (along the lines of the changed thread 
title) why other browsers are not, as it appears, interested in making 
this part of a specification effort.


Although there might not yet be interest to make some official standard 
for browser add-ons at this point, I would think that in this one 
crucial area, browsers could consider allowing extension authors and web 
developers the ability to have a common means, regardless of browser, of 
communicating back-and-forth in the same "protocol" by using custom DOM 
events in this way as Firefox currently does. It is no small 
functionality to allow websites the abiility to communicate with add-ons 
and in an extensible manner.


Despite being an advocate of open source and open formats myself, I 
strongly disagree with the sentiment I have heard some express, that the 
ability to make custom formats within X/HTML, whether through namespaced 
elements and attributes or processing instructions (both regrettably 
disallowed by HTML at present, in my view) or by custom DOM events, is 
only promoting proprietary formats.


On the contrary, I feel that such ability to experiment allows new 
standards to emerge which meet needs that HTML is not presently willing 
to implement.


Here are just a few use cases, though the list could really go on and on:
1) Allowing websites to interact with client-side chat clients for 
real-time collaboration by site visitors (as the Firefox extension 
SamePlace does)
2) Allowing websites to share and access each other's databases when 
permitted by the site (or even by the user alone)
a) Adoption of more specific shared database formats in a specific 
genre like the ability to view, schedule, and edit meetings or events
3) Supporting the ability to query XML databases with powerful XQuery 
and update facilities through the browser.


While it is great that the big browsers have settled on avoiding too 
extreme a competition with their own new markup, going through standards 
bodies at least in cases like  where there is no need for 1000 
different ways to express the markup (even while the case could be made 
for allowing 1000 different namespaced attributes on the tag until 
standardization is complete), smaller sites or special interests if not 
bigger organizations as well, still need the ability to innovate. The 
web will clearly not settle for perpetually proprietary formats anyways, 
except in cases where the standards have not yet caught up.  And 
"proprietary" here is a relative term since the underlying platform 
(DOM/XML) is still itself standardized.


Better to give the means for innovation in the first place but in a way 
which can be made to work cross-browser, rather than shut the door and 
treat web innovators and users paternalistically if not outright 
domineering them by maintaining exclusive control in the name of their 
supposed interest. While it is great that web authors have not been 
precipitously forced to use XML, it is a pity, in my view, that the 
extensibility of XML has not been carried over and embraced, even if a 
co-editor of XML himself (reasonably) suggested avoiding creating new 
dialects where possible. Please give us at least one means of extending 
functionality beyond what you currently happen to support or want to 
support...


Brett

[IndexedDB] .value of no-duplicate cursors

[Jonas Sicking]

Hi All,

This was one issue we ran into while implementing IndexedDB. In the
code examples I'll use the mozilla proposed asynchronous APIs, but the
issue applies equally to the spec as it is now, as well as the
synchronous APIs.

Consider an objectStore containing the following objects:

{ id: 1, name: "foo", flags: ["hi", "low"] }
{ id: 2, name: "foo", flags: ["apple", "orange"] }
{ id: 3, name: "foo", flags: ["hello", "world"] }
{ id: 4, name: "bar", flags: ["fahrvergnügen"] }

And an index keyed on the "name" property. What should the following code alert?

results = [];
db.objectStore("myObjectStore").index("nameIndex").openCursor(null,
IDBCursor.NEXT_NO_DUPLICATE).onsuccess = function(e) {
  cursor = e.result;
  if (!cursor) {
alert(results.length);
alert(results);
  }
  results.push(cursor.value);
  cursor.continue();
};

It's clear that the first alert would display '2', as there are 2
distinct 'name' values in the objectStore. However it's not clear what
the second alert would show. I.e. what would cursor.value be on each
'success' event firing?

We could define that it is one of the rows matching the distinct
value. In that case either "1,4", "2,4" or "3,4" would be valid values
for the second alert. If we choose that solution then ideally we
should define which one and make it consistent in all implementations.

Alternatively we could say that .value is null for all *_NO_DUPLICATE cursors.

The question equally applies if the above code used openObjectCursor
rather than openCursor. However if we define that .value is null for
*_NO_DUPLICATE cursors, then openObjectCursor with *_NO_DUPLICATE
doesn't make much sense in that it returns the same thing as
openCursor with *_NO_DUPLICATE.

I don't personally don't care much which solution we use. I'm unclear
on what the exact use cases are for *_NO_DUPLICATE cursors. However if
we do say that .value should represent a particular row, then I think
we should define which row is returned.

/ Jonas

Re: [IndexedDB] Should .add/.put/.update throw when called in read-only transaction?

[Jonas Sicking]

On Wed, Jun 30, 2010 at 6:42 PM, Jeremy Orlow  wrote:
> On Thu, Jul 1, 2010 at 11:17 AM, Jonas Sicking  wrote:
>>
>> Hi All,
>>
>> Currently the IndexedDB specification is silent on what should happen
>> if IDBObjectStore.add, IDBObjectStore.put, IDBObjectStore.remove,
>> IDBCursor.update or IDBCursor.remove() is called from a READ_ONLY
>> transaction. There are two possible ways we can handle this:
>>
>> 1. We can throw an exception.
>> 2. We can return a IDBRequest object and asynchronously fire a 'error'
>> event on this object.
>>
>> The advantage of 1 is that we pretty much know that this was an error
>> due to a bug in the web page, and we can always know this
>> synchronously without having to consult the database. Throwing an
>> error means that all the existing infrastructure for error handling
>> with automatically kick in. For example any higher-level try/catch
>> constructs will have an opportunity to catch the error.
>> Implementations generally report uncaught exceptions to an error log.
>> The browser will fire an 'error' event on the window which the page
>> can use for further logging. Firing an error event on the other hand
>> does not allow the browser to automatically log the error in a console
>> as the page hasn't yet gotten a chance to handle it.
>>
>> The advantage of 2 is that this is consistent with other error
>> conditions, such as writing duplicate keys, disk errors during writing
>> the database to disk, internal errors in the database, etc.
>>
>> While consistency, and only needing to check for errors one way, is
>> certainly good arguments, I would argue that people won't need to
>> check for calling-add-on-read-only-transactions. For properly written
>> code it's not an error that will occur, and thus there is no need to
>> check for it. In fact, you probably are generally better off letting
>> the exception bubble all the way up and get logged or caught by
>> generic error handlers.
>>
>> Additionally, the structured clone algorithm, which defines that an
>> exception should synchronously be thrown if the object is malformed,
>> for example if it consists of a cyclic graph. So .add/.put/.update can
>> already throw under certain circumstances.
>>
>> Also compare to if we were using a different API strategy of making
>> objectStores and cursors returned from READ_ONLY transactions not have
>> mutating functions. In this case if someone tried to call .put(), that
>> also would result in a exception from the JS interpreter stating that
>> you're calling a function that doesn't exist.
>>
>> So I would argue that we should throw for at least all transaction
>> violations. I.e. whenever you try to perform an action not allowed by
>> the current transaction. This would also cover the case of calling
>> createObjectStore/removeObjectStore/createIndex/removeIndex during a
>> non-setVersion-transaction.
>>
>>
>> There is also another case where synchronously know that an error will
>> be reported. We could throw when IDBCursor.update() is called when the
>> underlying object store uses in-line keys and the property at the key
>> path does not match the key in this cursor's position. In this case we
>> similarly immediately know that there is an error without having to
>> consult the database. We also generally can be sure that there is a
>> bug in the web page which would benefit from being reported like other
>> bugs are.
>>
>> And like stated above, IDBCursor.update() can already throw if the
>> passed in object can't be structurally cloned.
>>
>>
>> Jeremy previously asked if there was a test we could use to
>> clearly/intuitively break error conditions into two groups. Ones that
>> cause exceptions to be thrown, and ones that cause error events to be
>> fired. I would say that errors that do not depend on what data is in
>> the database, but rather are clearly due to errors at the call site
>> should throw an exception.
>
> This would limit us in the future in terms of schema changes.  The current
> async interface differs starting the transaction until the first call that
> accesses/modifies data (which are all async).  If we ever allow a schema
> change to happen without disconnecting all clients, it'd be possible that
> the objectStore could be deleted between when the call is made and when the
> transaction is actually allowed to start.

I'm not quite following here. Even if we in the future allow
objectStores to be deleted while there are transactions open against
it, then .add/.put would still know if we're inside a READ_ONLY or
READ_WRITE transaction, no? And so could still throw an error if we're
in a READ_ONLY transaction.

By the test defined above, .put would in that situation have to fire
an error event, rather than throw, if properly called on an READ_WRITE
transaction, but where the objectStore had been deleted. This because
we would have to check with the database if the objectStore was
deleted and thus would fail the "do not depend on what data is in the
database

Re: [IndexedDB] Should .add/.put/.update throw when called in read-only transaction?

[Jeremy Orlow]

On Thu, Jul 1, 2010 at 11:17 AM, Jonas Sicking  wrote:

> Hi All,
>
> Currently the IndexedDB specification is silent on what should happen
> if IDBObjectStore.add, IDBObjectStore.put, IDBObjectStore.remove,
> IDBCursor.update or IDBCursor.remove() is called from a READ_ONLY
> transaction. There are two possible ways we can handle this:
>
> 1. We can throw an exception.
> 2. We can return a IDBRequest object and asynchronously fire a 'error'
> event on this object.
>
> The advantage of 1 is that we pretty much know that this was an error
> due to a bug in the web page, and we can always know this
> synchronously without having to consult the database. Throwing an
> error means that all the existing infrastructure for error handling
> with automatically kick in. For example any higher-level try/catch
> constructs will have an opportunity to catch the error.
> Implementations generally report uncaught exceptions to an error log.
> The browser will fire an 'error' event on the window which the page
> can use for further logging. Firing an error event on the other hand
> does not allow the browser to automatically log the error in a console
> as the page hasn't yet gotten a chance to handle it.
>
> The advantage of 2 is that this is consistent with other error
> conditions, such as writing duplicate keys, disk errors during writing
> the database to disk, internal errors in the database, etc.
>
> While consistency, and only needing to check for errors one way, is
> certainly good arguments, I would argue that people won't need to
> check for calling-add-on-read-only-transactions. For properly written
> code it's not an error that will occur, and thus there is no need to
> check for it. In fact, you probably are generally better off letting
> the exception bubble all the way up and get logged or caught by
> generic error handlers.
>
> Additionally, the structured clone algorithm, which defines that an
> exception should synchronously be thrown if the object is malformed,
> for example if it consists of a cyclic graph. So .add/.put/.update can
> already throw under certain circumstances.
>
> Also compare to if we were using a different API strategy of making
> objectStores and cursors returned from READ_ONLY transactions not have
> mutating functions. In this case if someone tried to call .put(), that
> also would result in a exception from the JS interpreter stating that
> you're calling a function that doesn't exist.
>
> So I would argue that we should throw for at least all transaction
> violations. I.e. whenever you try to perform an action not allowed by
> the current transaction. This would also cover the case of calling
> createObjectStore/removeObjectStore/createIndex/removeIndex during a
> non-setVersion-transaction.
>
>
> There is also another case where synchronously know that an error will
> be reported. We could throw when IDBCursor.update() is called when the
> underlying object store uses in-line keys and the property at the key
> path does not match the key in this cursor's position. In this case we
> similarly immediately know that there is an error without having to
> consult the database. We also generally can be sure that there is a
> bug in the web page which would benefit from being reported like other
> bugs are.
>
> And like stated above, IDBCursor.update() can already throw if the
> passed in object can't be structurally cloned.
>
>
> Jeremy previously asked if there was a test we could use to
> clearly/intuitively break error conditions into two groups. Ones that
> cause exceptions to be thrown, and ones that cause error events to be
> fired. I would say that errors that do not depend on what data is in
> the database, but rather are clearly due to errors at the call site
> should throw an exception.
>

This would limit us in the future in terms of schema changes.  The current
async interface differs starting the transaction until the first call that
accesses/modifies data (which are all async).  If we ever allow a schema
change to happen without disconnecting all clients, it'd be possible that
the objectStore could be deleted between when the call is made and when the
transaction is actually allowed to start.

This also will limit what can be done on a background thread.  For example,
an implementation couldn't do serialization of the object on a background
thread (yes, if you did this, you'd need to make sure the main thread didn't
modify it until it finished serializing).

Because of these reasons, I'm not too excited about this particular
heuristic for when to throw vs fire an error callback.  I've thought about
it a bit and can't think of anything better though, unfortunately.

I think I'm still slightly in favor of routing all errors through onerror
callbacks and never throwing from a function that returns an IDBResult, but
I think there were some good points brought up by Jonas for why throwing on
some errors would make sense.


> Let me know what you think.
>
> / Jonas
>
>

[IndexedDB] Should .add/.put/.update throw when called in read-only transaction?

[Jonas Sicking]

Hi All,

Currently the IndexedDB specification is silent on what should happen
if IDBObjectStore.add, IDBObjectStore.put, IDBObjectStore.remove,
IDBCursor.update or IDBCursor.remove() is called from a READ_ONLY
transaction. There are two possible ways we can handle this:

1. We can throw an exception.
2. We can return a IDBRequest object and asynchronously fire a 'error'
event on this object.

The advantage of 1 is that we pretty much know that this was an error
due to a bug in the web page, and we can always know this
synchronously without having to consult the database. Throwing an
error means that all the existing infrastructure for error handling
with automatically kick in. For example any higher-level try/catch
constructs will have an opportunity to catch the error.
Implementations generally report uncaught exceptions to an error log.
The browser will fire an 'error' event on the window which the page
can use for further logging. Firing an error event on the other hand
does not allow the browser to automatically log the error in a console
as the page hasn't yet gotten a chance to handle it.

The advantage of 2 is that this is consistent with other error
conditions, such as writing duplicate keys, disk errors during writing
the database to disk, internal errors in the database, etc.

While consistency, and only needing to check for errors one way, is
certainly good arguments, I would argue that people won't need to
check for calling-add-on-read-only-transactions. For properly written
code it's not an error that will occur, and thus there is no need to
check for it. In fact, you probably are generally better off letting
the exception bubble all the way up and get logged or caught by
generic error handlers.

Additionally, the structured clone algorithm, which defines that an
exception should synchronously be thrown if the object is malformed,
for example if it consists of a cyclic graph. So .add/.put/.update can
already throw under certain circumstances.

Also compare to if we were using a different API strategy of making
objectStores and cursors returned from READ_ONLY transactions not have
mutating functions. In this case if someone tried to call .put(), that
also would result in a exception from the JS interpreter stating that
you're calling a function that doesn't exist.

So I would argue that we should throw for at least all transaction
violations. I.e. whenever you try to perform an action not allowed by
the current transaction. This would also cover the case of calling
createObjectStore/removeObjectStore/createIndex/removeIndex during a
non-setVersion-transaction.


There is also another case where synchronously know that an error will
be reported. We could throw when IDBCursor.update() is called when the
underlying object store uses in-line keys and the property at the key
path does not match the key in this cursor's position. In this case we
similarly immediately know that there is an error without having to
consult the database. We also generally can be sure that there is a
bug in the web page which would benefit from being reported like other
bugs are.

And like stated above, IDBCursor.update() can already throw if the
passed in object can't be structurally cloned.


Jeremy previously asked if there was a test we could use to
clearly/intuitively break error conditions into two groups. Ones that
cause exceptions to be thrown, and ones that cause error events to be
fired. I would say that errors that do not depend on what data is in
the database, but rather are clearly due to errors at the call site
should throw an exception.

Let me know what you think.

/ Jonas

Re: [File API] Recent Updates To Specification + Co-Editor

[Jian Li]

Thanks for the update. We've some more questions regarding the blob URL.

1. The spec does not describe how blob and blob URL will work in the worker
and shared worker scenarios. I think we should allow WorkerGlobalScope to be
the binding context for the blob URL, like Document. In addition, we should
define how a blob object can be passed to the worker via structured cloning.
A new blob object should be expected to be created and it points to the same
underlying data.

2. The current spec says that the lifetime of the blob URL is bound to the
lifetime of the spawning context. What happens if we try to access the blob
url from multiple contexts? Say, we
call "parent.blob.url", the lifetime of the url is bound to the parent
context, not the current context, per the spec. This sounds a little bit
unnatural. Could we explicitly provide the context while creating the blob
URL, like "window.createBlobUrl(blob)"?

3. Since the lifetime of the blob URL is bound to a context, the blob URL
(the underlying blob data) will get disposed only when the context dies.
When we have long-live pages or shared workers, we could have "leaked" blob
URLs that result in unclaimed blob storages. It will be nice if we can add
the capability to revoke the blob URL pragmatically,
like "window.revokeBlobUrl(url)",

4. It will be good if the spec could say more about the lifetime of the blob
object and the blob URL since they're kind of orthogonal: the blob object
will still be functional as long as it is not GC-ed even if the associated
context dies.

5. The spec does not describe explicitly about the transient cases, like
"location.href = blob.url". Probably the spec could mention that the
resource pointed by blob URL should be loaded successfully as long as the
blob URL is valid at the time when the resource is starting to load.


On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan  wrote:

> Greetings WebApps WG,
>
> I have made edits to the File API specification [1].  There are a few
> things of note that I'd like to call the WG's attention to.
>
> 1. There is a name change in effect.  FileReader has been re-named
> BlobReader, upon request from Chrome team folks[2][3].  The name
> "BlobReader" won't win awards in a beauty pageant, but it tersely describes
> an object to read Blobs (which could originate from the underlying file
> system *or* be generated *within* a Web App).  My present understanding is
> that FileWriter will also undergo a name change.  Naming is really hard.
>  Firefox already ships with FileReader, but I see the point of having an
> object named for what it does, which in this case is certainly more than
> file reading from the underlying file system.  I also abhor bike shedding,
> especially over naming, but this is something that's exposed to the authors.
>  I have not renamed FileError or FileException.  In the case of errors and
> exceptions, I think *most* scenarios will occur as a result of issues with
> the underlying file system.  These names should remain.
>
> 2. I've updated the URL scheme for Blobs using an ABNF that calls for an
> "opaque string" which is a term I define in the specification.  There was
> much discussion about this aspect of the File API specification, and I think
> the existing scheme does allow for user agents to tack on origin information
> in the URL (this is not something the spec. says you should do).  The actual
> choice of opaque string is left to implementations, though the specification
> suggests UUID in its canonical form (and provides an ABNF for this).  I
> think this is the most any specification has said on the subject of URLs.
>
> 3. There is an additional asynchronous read method on BlobReader, and an
> additional synchronous read method on BlobReaderSync, namely
> readAsArrayBuffer.  These use the TypedArrays definition initially defined
> by the WebGL WG [4].
>
> 4. I am moving on from my full-time role at Mozilla to a part-time
> consulting role.  I'll continue to be an editor of the File API, but I am
> stepping down as Chair of the WebGL WG.  I'll continue to be active in
> standards communities, though :-)
>
> 5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor of
> the File API specification.  Most people who work on HTML5 and WebApps know
> Jonas' contributions to both WGs; with everyone's consent, I'd like to
> nominate him as co-editor.  His model for an asynchronous event-driven API
> is what prompted the initial rewrite, and he also works on both File API and
> IndexedDB implementation (amongst other things).
>
> -- A*
>
> [1] http://dev.w3.org/2006/webapi/FileAPI/
> [2]
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html
> [3]
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html
> [4]
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
>
>

Re: [File API] Recent Updates To Specification + Co-Editor

[Jian Li]

We've some more questions regarding the blob URL.

1. The spec does not describe how blob and blob URL will work in the worker
and shared worker scenarios. I think we should allow WorkerGlobalScope to be
the binding context for the blob URL, like Document. In addition, we should
define how a blob object can be passed to the worker via structured cloning.
A new blob object should be expected to be created and it points to the same
underlying data.

2. The current spec says that the lifetime of the blob URL is bound to the
lifetime of the spawning context. What happens if we try to access the blob
url from multiple contexts? Say, we
call "parent.blob.url", the lifetime of the url is bound to the parent
context, not the current context, per the spec. This sounds a little bit
unnatural. Could we explicitly provide the context while creating the blob
URL, like "window.createBlobUrl(blob)"?

3. Since the lifetime of the blob URL is bound to a context, the blob URL
(the underlying blob data) will get disposed only when the context dies.
When we have long-live pages or shared workers, we could have "leaked" blob
URLs that result in unclaimed blob storages. It will be nice if we can add
the capability to revoke the blob URL pragmatically,
like "window.revokeBlobUrl(url)",

4. It will be good if the spec could say more about the lifetime of the blob
object and the blob URL since they're kind of orthogonal: the blob object
will still be functional as long as it is not GC-ed even if the associated
context dies.

5. The spec does not describe explicitly about the transient cases, like
"location.href = blob.url". Probably the spec could mention that the
resource pointed by blob URL should be loaded successfully as long as the
blob URL is valid at the time when the resource is starting to load.



On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan  wrote:

> Greetings WebApps WG,
>
> I have made edits to the File API specification [1].  There are a few
> things of note that I'd like to call the WG's attention to.
>
> 1. There is a name change in effect.  FileReader has been re-named
> BlobReader, upon request from Chrome team folks[2][3].  The name
> "BlobReader" won't win awards in a beauty pageant, but it tersely describes
> an object to read Blobs (which could originate from the underlying file
> system *or* be generated *within* a Web App).  My present understanding is
> that FileWriter will also undergo a name change.  Naming is really hard.
>  Firefox already ships with FileReader, but I see the point of having an
> object named for what it does, which in this case is certainly more than
> file reading from the underlying file system.  I also abhor bike shedding,
> especially over naming, but this is something that's exposed to the authors.
>  I have not renamed FileError or FileException.  In the case of errors and
> exceptions, I think *most* scenarios will occur as a result of issues with
> the underlying file system.  These names should remain.
>
> 2. I've updated the URL scheme for Blobs using an ABNF that calls for an
> "opaque string" which is a term I define in the specification.  There was
> much discussion about this aspect of the File API specification, and I think
> the existing scheme does allow for user agents to tack on origin information
> in the URL (this is not something the spec. says you should do).  The actual
> choice of opaque string is left to implementations, though the specification
> suggests UUID in its canonical form (and provides an ABNF for this).  I
> think this is the most any specification has said on the subject of URLs.
>
> 3. There is an additional asynchronous read method on BlobReader, and an
> additional synchronous read method on BlobReaderSync, namely
> readAsArrayBuffer.  These use the TypedArrays definition initially defined
> by the WebGL WG [4].
>
> 4. I am moving on from my full-time role at Mozilla to a part-time
> consulting role.  I'll continue to be an editor of the File API, but I am
> stepping down as Chair of the WebGL WG.  I'll continue to be active in
> standards communities, though :-)
>
> 5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor of
> the File API specification.  Most people who work on HTML5 and WebApps know
> Jonas' contributions to both WGs; with everyone's consent, I'd like to
> nominate him as co-editor.  His model for an asynchronous event-driven API
> is what prompted the initial rewrite, and he also works on both File API and
> IndexedDB implementation (amongst other things).
>
> -- A*
>
> [1] http://dev.w3.org/2006/webapi/FileAPI/
> [2]
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html
> [3]
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html
> [4]
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
>
>

Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

[Boris Zbarsky]

On 6/29/10 2:36 PM, Chris Wilson wrote:

See, this is exactly why we asked the question - because it seems that behavior 
is inconsistent, we're not sure what the expectation is.


Note that the Firefox behavior I described is irrelevant to 
specification efforts, because it's not visible to web pages


I think Anne answered the question, in any case: the XHR event target 
chain only contains the XHR object itself and nothing else.  If the spec 
doesn't say that explicitly, it should.


-Boris

[Work in Progress on "Web Notification" Working Group

[Arthur Barstow]

Earlier today the W3C posted a Draft charter for a new Web Notification 
Working Group:


  http://www.w3.org/2010/06/notification-charter

The primary objective of this WG is to move the Web Notifications spec 
to Recommendation:


  http://dev.w3.org/2006/webapi/WebNotifications/publish/

If you have any comments about the Draft charter, please send them to:

  public-webapps@w3.org

-Art Barstow

Re: BlobWriter simplification/split

[Michael Nordman]

On Wed, Jun 30, 2010 at 10:29 AM, Eric Uhrhane  wrote:

> On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking  wrote:
> > On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane  wrote:
> >> Following up on discussions mainly at [1] and use cases at [2], I'd
> >> like to propose splitting the BlobWriter [née FileWriter] class, with
> >> an eye to solving some UI problems and simplifying implementation.
> >>
> >> When saving a Blob to a location outside the FileSystem API sandbox,
> >> we want to prompt the user exactly once, and want to be able to
> >> indicate that a write is taking place, e.g. by throbbing the download
> >> indicator.  We want the throbbing to go away as soon as the write is
> >> done, and we don't want the app to have continued privileges to write
> >> outside the sandbox.  [That's been debated, but I think it's beyond
> >> the scope of what we're working on so far, so let's leave that case
> >> for later expansion.]
> >>
> >> When writing inside the sandbox, we probably don't need the throbber
> >> at all, and we definitely don't want to prompt the user on each write.
> >>  Leaving aside the question of how one obtains a BlobWriter without
> >> using the sandbox and when exactly prompts happen [I'll open another
> >> thread for that], I think that:
> >>
> >> *  We don't want to have the same API call cause prompts to pop up on
> >> some instances of BlobWriter and not others.
> >> *  We don't want to have the same API call be reusable on some
> >> instances of BlobWriter and not others.
> >>
> >> I propose the following split:
> >>
> >> Define a parent class, SimpleBlobWriter, that's used for one-shot Blob
> >> export.  This is what you use when you don't have the FileSystem API,
> >> when the user selects the save location.  It contains a writeFile()
> >> method, which writes a Blob to a file in a single operation.  It is an
> >> error to call writeFile if readyState is not INIT, so SimpleBlobWriter
> >> is single-use.  Its other members are abort(), readyState, the ready
> >> state constants, error, length, and the progress event handlers, as
> >> defined in the current spec.
> >>
> >> Derive from SimpleBlobWriter the class BlobWriter, which adds
> >> position, truncate(), seek(), and write(), as defined in the current
> >> spec.  This is what the FileSystem API's createWriter() call would
> >> return.
> >>
> >> This lets you have different APIs for different behaviors, and removes
> >> fields from SimpleBlobWriter that aren't actually useful without the
> >> FileSystem API.
> >>
> >> How does that sound?
> >
> > Sounds great!
> >
> >> [Better names for SimpleBlobWriter and
> >> BlobWriter would be quite welcome, BTW.]
> >
> > May I propose FileWriter in place of BlobWriter? ;-)
> > You are actually always writing to files, so it would make a lot of sense
> IMO.
>
> We renamed BlobReader based on the perspective that it took data from
> a Blob and read it into memory.  Likewise BlobWriter takes data from a
> Blob and writes it to a file.  I think the symmetry makes sense.
> Calling it FileWriter also works, but then you're naming by
> destination instead of source, so I don't think it complements
> BlobReader as well.
>
> > An alternative would be to rename SimpleBlobWriter to FileSaver and
> > have the two be completely separate interfaces. It doesn't seem like
> > the inheritance is adding much anyway?
>
> I do like *Saver, though, since it clearly just saves an entire Blob.
> How about BlobSaver [with method save() instead of writeFile] and
> BlobWriter?
>
> The inheritance gets you length, abort(), error, the state constants,
> and all the progress events, which may have identical handlers in many
> cases.  I think that's probably enough to be worthwhile.  Anyone else
> want to chime in?
>

*Saver.save() is very good naming, short and sweet and tersely accurate.

As for the (*) noun. Whatever noun is chosen, it should probably be used for
the entire family (*Saver, *Reader, *Writer) for consistency. Also I don't
think its safe to assume that a *Saver interface will only ever be used to
dump a blob to a file (Jonas mentioned the possibility of dumping a blob
into an IndexedDB). These things make me lean towards Blob as the noun. Of
course... Y (bikeshed) MMV.

Re: BlobWriter simplification/split

[Eric Uhrhane]

On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking  wrote:
> On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane  wrote:
>> Following up on discussions mainly at [1] and use cases at [2], I'd
>> like to propose splitting the BlobWriter [née FileWriter] class, with
>> an eye to solving some UI problems and simplifying implementation.
>>
>> When saving a Blob to a location outside the FileSystem API sandbox,
>> we want to prompt the user exactly once, and want to be able to
>> indicate that a write is taking place, e.g. by throbbing the download
>> indicator.  We want the throbbing to go away as soon as the write is
>> done, and we don't want the app to have continued privileges to write
>> outside the sandbox.  [That's been debated, but I think it's beyond
>> the scope of what we're working on so far, so let's leave that case
>> for later expansion.]
>>
>> When writing inside the sandbox, we probably don't need the throbber
>> at all, and we definitely don't want to prompt the user on each write.
>>  Leaving aside the question of how one obtains a BlobWriter without
>> using the sandbox and when exactly prompts happen [I'll open another
>> thread for that], I think that:
>>
>> *  We don't want to have the same API call cause prompts to pop up on
>> some instances of BlobWriter and not others.
>> *  We don't want to have the same API call be reusable on some
>> instances of BlobWriter and not others.
>>
>> I propose the following split:
>>
>> Define a parent class, SimpleBlobWriter, that's used for one-shot Blob
>> export.  This is what you use when you don't have the FileSystem API,
>> when the user selects the save location.  It contains a writeFile()
>> method, which writes a Blob to a file in a single operation.  It is an
>> error to call writeFile if readyState is not INIT, so SimpleBlobWriter
>> is single-use.  Its other members are abort(), readyState, the ready
>> state constants, error, length, and the progress event handlers, as
>> defined in the current spec.
>>
>> Derive from SimpleBlobWriter the class BlobWriter, which adds
>> position, truncate(), seek(), and write(), as defined in the current
>> spec.  This is what the FileSystem API's createWriter() call would
>> return.
>>
>> This lets you have different APIs for different behaviors, and removes
>> fields from SimpleBlobWriter that aren't actually useful without the
>> FileSystem API.
>>
>> How does that sound?
>
> Sounds great!
>
>> [Better names for SimpleBlobWriter and
>> BlobWriter would be quite welcome, BTW.]
>
> May I propose FileWriter in place of BlobWriter? ;-)
> You are actually always writing to files, so it would make a lot of sense IMO.

We renamed BlobReader based on the perspective that it took data from
a Blob and read it into memory.  Likewise BlobWriter takes data from a
Blob and writes it to a file.  I think the symmetry makes sense.
Calling it FileWriter also works, but then you're naming by
destination instead of source, so I don't think it complements
BlobReader as well.

> An alternative would be to rename SimpleBlobWriter to FileSaver and
> have the two be completely separate interfaces. It doesn't seem like
> the inheritance is adding much anyway?

I do like *Saver, though, since it clearly just saves an entire Blob.
How about BlobSaver [with method save() instead of writeFile] and
BlobWriter?

The inheritance gets you length, abort(), error, the state constants,
and all the progress events, which may have identical handlers in many
cases.  I think that's probably enough to be worthwhile.  Anyone else
want to chime in?

 Eric

Re: BlobWriter simplification/split

[Jonas Sicking]

On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane  wrote:
> Following up on discussions mainly at [1] and use cases at [2], I'd
> like to propose splitting the BlobWriter [née FileWriter] class, with
> an eye to solving some UI problems and simplifying implementation.
>
> When saving a Blob to a location outside the FileSystem API sandbox,
> we want to prompt the user exactly once, and want to be able to
> indicate that a write is taking place, e.g. by throbbing the download
> indicator.  We want the throbbing to go away as soon as the write is
> done, and we don't want the app to have continued privileges to write
> outside the sandbox.  [That's been debated, but I think it's beyond
> the scope of what we're working on so far, so let's leave that case
> for later expansion.]
>
> When writing inside the sandbox, we probably don't need the throbber
> at all, and we definitely don't want to prompt the user on each write.
>  Leaving aside the question of how one obtains a BlobWriter without
> using the sandbox and when exactly prompts happen [I'll open another
> thread for that], I think that:
>
> *  We don't want to have the same API call cause prompts to pop up on
> some instances of BlobWriter and not others.
> *  We don't want to have the same API call be reusable on some
> instances of BlobWriter and not others.
>
> I propose the following split:
>
> Define a parent class, SimpleBlobWriter, that's used for one-shot Blob
> export.  This is what you use when you don't have the FileSystem API,
> when the user selects the save location.  It contains a writeFile()
> method, which writes a Blob to a file in a single operation.  It is an
> error to call writeFile if readyState is not INIT, so SimpleBlobWriter
> is single-use.  Its other members are abort(), readyState, the ready
> state constants, error, length, and the progress event handlers, as
> defined in the current spec.
>
> Derive from SimpleBlobWriter the class BlobWriter, which adds
> position, truncate(), seek(), and write(), as defined in the current
> spec.  This is what the FileSystem API's createWriter() call would
> return.
>
> This lets you have different APIs for different behaviors, and removes
> fields from SimpleBlobWriter that aren't actually useful without the
> FileSystem API.
>
> How does that sound?

Sounds great!

> [Better names for SimpleBlobWriter and
> BlobWriter would be quite welcome, BTW.]

May I propose FileWriter in place of BlobWriter? ;-)
You are actually always writing to files, so it would make a lot of sense IMO.

An alternative would be to rename SimpleBlobWriter to FileSaver and
have the two be completely separate interfaces. It doesn't seem like
the inheritance is adding much anyway?

/ Jonas

Re: [IndexedDB] IDBEvent and Event

[Shawn Wilsher]

On 6/30/2010 8:25 AM, Andrei Popescu wrote:

Agreed. In WebKit, Jeremy already made it inherit from Event.

I filed bug 10056 [1] on this.

Cheers,

Shawn

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10056



smime.p7s
Description: S/MIME Cryptographic Signature

[Bug 10056] New: IDBEvent should inherit from DOM Level 3 Event

[bugzilla]

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

   Summary: IDBEvent should inherit from DOM Level 3 Event
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
   URL: http://www.w3.org/TR/DOM-Level-3-Events/#interface-Eve
nt
OS/Version: Windows NT
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: nikunj.me...@oracle.com
ReportedBy: sdwi...@forerunnerdesigns.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Per
http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg1178,
we should make IDBEvent inherit from Event.

-- 
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.

OMTP BONDI 1.11 errata release

[David Rogers]

Dear all,

 

Please note that the OMTP BONDI 1.11 errata release specifications are
available at: http://bondi.omtp.org/1.11/ . These contain minor changes
and editorial updates to the previously released 1.1 version:
http://bondi.omtp.org/1.1/ .

 

Thanks,

 


David.

 

David Rogers
OMTP Director of External Relations 

 

Re: [IndexedDB] IDBEvent and Event

[Andrei Popescu]

On Sat, Jun 26, 2010 at 12:41 PM, Jonas Sicking  wrote:
> On Fri, Jun 25, 2010 at 2:20 PM, Shawn Wilsher  wrote:
>> Hey all,
>>
>> I think that IDBEvent needs to inherit from Event [1] in order for us to
>> properly inherit from EventTarget in IDBRequest.  Specifically, EventTarget
>> takes an EventListener [2] which has a method, handleEvent, that takes an
>> Event object.  I'm not sure this makes sense for us though, so I figured I'd
>> start a discussion before filing the bug.
>>
>> Cheers,
>>
>> Shawn
>>
>> [1] http://www.w3.org/TR/DOM-Level-3-Events/#interface-Event
>> [2] http://www.w3.org/TR/DOM-Level-3-Events/#interface-EventListener
>
> Technically I don't think inheriting from Event is required. You can
> generally always use language specific means of casting between
> interfaces. This is how for example Document [1] and DocumentTraversal
> [2] are related. I.e. even though you receive an Event object in
> handleEvent, you can always cast that to IDBEvent using whatever
> casting mechanism your language have.
>
> However if we want to follow the pattern used everywhere else for
> events [3], and I definitely think we do, then IDBEvent should indeed
> inherit from Event.
>

Agreed. In WebKit, Jeremy already made it inherit from Event.

http://trac.webkit.org/browser/trunk/WebCore/storage/IDBEvent.idl#L33

Thanks,
Andrei

Re: [widgets] API - openURL security considerations

[Scott Wilson]

On 30 Jun 2010, at 14:30, Marcos Caceres wrote:

> I've evaluated the discussions in this thread and am strongly leaning
> towards proposing we drop openURL() from the specification on privacy
> and security grounds.
> 
> Although I can think of cases where it might be useful to have a
> widget programmatically call openURL (e.g., "when it's 5pm, and if I'm
> at home, sms these people and let him know 'I'm here, bring beer!'"),
> there are just too many abuse cases and complexities.

I haven't seen too many examples of OpenURL() in the wild, and in Wookie you 
may as well just use HTML  and window.open() as its running in a browser 
anyway. The UC would be for environments where window.open() was not handled by 
the UA; however implementing that would probably be better effort spent than 
implementing widget.openURL().

> I think we should follow Adam's advice from May 10 and just make URL
> handling reliant on a declarative model (i.e., leave it to HTML's a
> element and friends, as suggested by Adam below):
> 
>> 1) Remove the API and replace it with a declarative API, like a
>> hyperlink.  Remove the ability to programmatically click the hyperlink
>> and instead rely on the user actually clicking the link.  This
>> approach is related to the "browser button" element discussed in the
>> HTML working group for dealing with similar security issues with
>> programmatic access to other APIs.
> 
> I'm unsure if we should get HTML5 to specify this, or if we should
> specify this behavior (if they don't already). I personally think the
> widgets API spec would be overreaching if it started saying how URI
> handling in HTML should be done.
> 
>> 2) If we require an imperative API for following a hyperlink, restrict
>> the API to a whitelist of known-safe URL schemes.  We can allow user
>> agents to extend this list with a registry of known-safe URL schemes,
>> but we shouldn't allow access to random side-effecting schemes like
>> sms (to pick an example from the spec) by default.
> 
> I'm still thinking we could drop openURL for this version and then add
> it once we work out all the kinks and if developers really cannot live
> without it.

Sounds fine by me +1

> 
> 
> 
> 
> 
> 
> 
> On Tue, May 11, 2010 at 6:28 PM, Arthur Barstow  wrote:
>> Several responses to this thread were made by Thomas and Adam and since
>> those responses are not archived in a Public area, with their permission,
>> here are all of the responses, starting with the oldest.
>> 
>> The last Public response to this thread is:
>> 
>> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0465.html
>> 
>> -Art Barstow
>> 
>> 
>> ** From: w...@adambarth.com
>> Subject: Re: [widgets] API - openURL security considerations
>> Date: May 10, 2010 12:15:38 PM EDT
>> 
>> It's lame that we're using a blacklist instead of a whitelist here.
>> Also this recommendation is somewhat useless:
>> 
>> "it is recommended that the user agent prompt the user for
>> confirmation before passing the URI to a scheme handler"
>> 
>> It's unlikely that users will have much context for understanding the
>> consequences of this confirmation experience and hence will make poor
>> security decisions.
>> 
>> Personally, I think the API is poorly design and should be removed in
>> favor of something that is secure by design.  We're stuck with this
>> API in the web platform in the form of window.open(), but we'd be
>> better off without.  You can see all the machinations around popup
>> blockers and vulnerabilities that it has created.  Fpr example,
>> .
>> 
>> Adam
>> 
>> 
>> ** From: t...@w3.org
>> Subject: Re: [widgets] API - openURL security considerations
>> Date: May 10, 2010 3:21:07 PM EDT
>> 
>> On 10 May 2010, at 18:15, Adam Barth wrote:
>> 
>> 
>>> Personally, I think the API is poorly design and should be removed in
>>> favor of something that is secure by design.  We're stuck with this
>>> API in the web platform in the form of window.open(), but we'd be
>>> better off without.  You can see all the machinations around popup
>>> blockers and vulnerabilities that it has created.  Fpr example,
>>> .
>>> 
>> 
>> Are you suggesting to completely drop openURL from the widget API?  Or do
>> you suggest a redesign?
>> 
>> 
>> ** From: w...@adambarth.com
>> Subject: Re: [widgets] API - openURL security considerations
>> Date: May 10, 2010 3:36:11 PM EDT
>> 
>> On Mon, May 10, 2010 at 12:21 PM, Thomas Roessler  wrote:
>> 
>>> On 10 May 2010, at 18:15, Adam Barth wrote:
>>> 
 Personally, I think the API is poorly design and should be removed in
 favor of something that is secure by design.  We're stuck with this
 API in the web platform in the form of window.open(), but we'd be
 better off without.  You can see all the machinations around popup
 blockers and vulnerabilities that it has created.  Fpr example,
 

Re: [widgets] API - openURL security considerations

[Marcos Caceres]

I've evaluated the discussions in this thread and am strongly leaning
towards proposing we drop openURL() from the specification on privacy
and security grounds.

Although I can think of cases where it might be useful to have a
widget programmatically call openURL (e.g., "when it's 5pm, and if I'm
at home, sms these people and let him know 'I'm here, bring beer!'"),
there are just too many abuse cases and complexities.

I think we should follow Adam's advice from May 10 and just make URL
handling reliant on a declarative model (i.e., leave it to HTML's a
element and friends, as suggested by Adam below):

> 1) Remove the API and replace it with a declarative API, like a
> hyperlink.  Remove the ability to programmatically click the hyperlink
> and instead rely on the user actually clicking the link.  This
> approach is related to the "browser button" element discussed in the
> HTML working group for dealing with similar security issues with
> programmatic access to other APIs.

I'm unsure if we should get HTML5 to specify this, or if we should
specify this behavior (if they don't already). I personally think the
widgets API spec would be overreaching if it started saying how URI
handling in HTML should be done.

> 2) If we require an imperative API for following a hyperlink, restrict
> the API to a whitelist of known-safe URL schemes.  We can allow user
> agents to extend this list with a registry of known-safe URL schemes,
> but we shouldn't allow access to random side-effecting schemes like
> sms (to pick an example from the spec) by default.

I'm still thinking we could drop openURL for this version and then add
it once we work out all the kinks and if developers really cannot live
without it.







On Tue, May 11, 2010 at 6:28 PM, Arthur Barstow  wrote:
> Several responses to this thread were made by Thomas and Adam and since
> those responses are not archived in a Public area, with their permission,
> here are all of the responses, starting with the oldest.
>
> The last Public response to this thread is:
>
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0465.html
>
> -Art Barstow
>
>
> ** From: w...@adambarth.com
> Subject: Re: [widgets] API - openURL security considerations
> Date: May 10, 2010 12:15:38 PM EDT
>
> It's lame that we're using a blacklist instead of a whitelist here.
> Also this recommendation is somewhat useless:
>
> "it is recommended that the user agent prompt the user for
> confirmation before passing the URI to a scheme handler"
>
> It's unlikely that users will have much context for understanding the
> consequences of this confirmation experience and hence will make poor
> security decisions.
>
> Personally, I think the API is poorly design and should be removed in
> favor of something that is secure by design.  We're stuck with this
> API in the web platform in the form of window.open(), but we'd be
> better off without.  You can see all the machinations around popup
> blockers and vulnerabilities that it has created.  Fpr example,
> .
>
> Adam
>
>
> ** From: t...@w3.org
> Subject: Re: [widgets] API - openURL security considerations
> Date: May 10, 2010 3:21:07 PM EDT
>
> On 10 May 2010, at 18:15, Adam Barth wrote:
>
>
>> Personally, I think the API is poorly design and should be removed in
>> favor of something that is secure by design.  We're stuck with this
>> API in the web platform in the form of window.open(), but we'd be
>> better off without.  You can see all the machinations around popup
>> blockers and vulnerabilities that it has created.  Fpr example,
>> .
>>
>
> Are you suggesting to completely drop openURL from the widget API?  Or do
> you suggest a redesign?
>
>
> ** From: w...@adambarth.com
> Subject: Re: [widgets] API - openURL security considerations
> Date: May 10, 2010 3:36:11 PM EDT
>
> On Mon, May 10, 2010 at 12:21 PM, Thomas Roessler  wrote:
>
>> On 10 May 2010, at 18:15, Adam Barth wrote:
>>
>>> Personally, I think the API is poorly design and should be removed in
>>> favor of something that is secure by design.  We're stuck with this
>>> API in the web platform in the form of window.open(), but we'd be
>>> better off without.  You can see all the machinations around popup
>>> blockers and vulnerabilities that it has created.  Fpr example,
>>> .
>>>
>>
>> Are you suggesting to completely drop openURL from the widget API?  Or do
>> you suggest a redesign?
>>
>
> I'm not familiar enough with the use cases for widgets to know what
> the alternatives are.  My perspective is that we'd be better off with
> a much weaker window.open() API in the web platform, but we're stuck
> with what we have.  In the widgets space, it seems like there's an
> opportunity to do something better that doesn't require us to reinvent
> popup blockers and all the other pseudo-security cruft we have around
> to deal 

Re: Fwd: [whatwg] what happened to sendAsBinary?

[Anne van Kesteren]

On Wed, 30 Jun 2010 13:48:47 +0200, Olli Pettay   
wrote:

XHR2 related discussion happens in WebApps WG.
Forwarding...

 Original Message 
Subject: [whatwg] what happened to sendAsBinary?
Date: Wed, 30 Jun 2010 13:27:09 +0300
From: Toni Ruottu 
To: wha...@whatwg.org

   hello

We are trying to code an application that needs to send some binary
data from javascript to a http server. The server is expecting to
receive the data in the body of the request, and for the body to not
include anything other than the raw data. In the old world you would
do this with the sendAsBinary function, available at least in Firefox.
How would you do the same thing with XHR2?


The plan is to overload send() with new types as they become available.  
The closest I suppose to "binary" is Blob object support.


See http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ for details.


--
Anne van Kesteren
http://annevankesteren.nl/

Fwd: [whatwg] what happened to sendAsBinary?

[Olli Pettay]

XHR2 related discussion happens in WebApps WG.
Forwarding...

 Original Message 
Subject: [whatwg] what happened to sendAsBinary?
Date: Wed, 30 Jun 2010 13:27:09 +0300
From: Toni Ruottu 
To: wha...@whatwg.org

  hello

We are trying to code an application that needs to send some binary
data from javascript to a http server. The server is expecting to
receive the data in the body of the request, and for the body to not
include anything other than the raw data. In the old world you would
do this with the sendAsBinary function, available at least in Firefox.
How would you do the same thing with XHR2?

  cheers, --Toni

[widgets] Draft agenda for 1 July 2010 voice conf

[Arthur Barstow]

Below is the draft agenda for the July 1 Widgets Voice Conference (VC).

Inputs and discussion before the VC on all of the agenda topics 
via public-webapps is encouraged (as it can result in a shortened 
meeting). Please address Open/Raised Issues and Open Actions before the 
meeting:


http://www.w3.org/2008/webapps/track/products/8

Minutes from the last VC:

http://www.w3.org/2010/06/17-wam-minutes.html

-Regards, Art Barstow

Agenda:

1. Review and tweak agenda

2. Announcements

3. Packaging and Configuration spec
http://dev.w3.org/2006/waf/widgets/

a. Issue-117  "In 
Widget P&C Spec, need to clarify in the spec that dir attribute does not 
apply to attributes that are IRIs, Numeric, Keywords, etc. The dir 
attribute only affects human readable strings."


4. Dependencies on draft specs and progressing to PR

Draft dependencies: 

PR process: 



5. Widget Interface spec
http://dev.w3.org/2006/waf/widgets-api/

a. Issue-116  "Need to 
flesh out the security considerations for the openURL method in the 
Widget Interface spec"


6. URI Scheme spec
http://dev.w3.org/cvsweb/2006/waf/widgets-uri/

a. Status and Open Actions:

 - "Widget URI scheme: 
define the widget *URI* syntax in terms of RFC 3986"


 - "Add requirements 
to Widget URIs based on what's in the requirements document"


7. AOB

Logistics:

 Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 
Boston; 06:00 Seattle

 Duration: 60 minutes max
 Zakim Bridge:+1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152
 PIN: 9231 ("WAF1");
 IRC: channel = #wam; irc://irc.w3.org:6665 ; 
http://cgi.w3.org/member-bin/irc/irc.cgi

 Confidentiality of minutes: Public

any plans to move from cvs to git?

[Matt Di Pasquale]

github rules!

Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

[Anne van Kesteren]

On Tue, 29 Jun 2010 23:36:28 +0200, Chris Wilson   
wrote:
See, this is exactly why we asked the question - because it seems that  
behavior is inconsistent, we're not sure what the expectation is.  The  
fact that the XHR spec says the events do not bubble (but says nothing  
about capture) is confusing.  DOM L3 Events says "here's what happens  
for DOM elements," but doesn't say explicitly if NOTHING should happen  
for non-DOM uses, or if something else should depending on context.


If nothing is stated nothing needs to be done. That Firefox does something  
with an object outside the Window object as well is not relevant. DOM  
Events defines the event flow for document trees. HTML5 defines how events  
are dispatched to Window in the event they are dispatched to Document.  
Trying to infer anything else from any of this is a mistake.  
XMLHttpRequest is neither part of the document tree nor is it the Window  
object, so logically its events will not go anywhere. Specifications need  
to be read literally.


We never say explicitly that "NOTHING" should happen. That is implied.  
Defining all the cases where "NOTHING" should happen is a race to the  
bottom.



--
Anne van Kesteren
http://annevankesteren.nl/