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

2010-06-30 Thread Anne van Kesteren
On Tue, 29 Jun 2010 23:36:28 +0200, Chris Wilson cwi...@microsoft.com  
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/



any plans to move from cvs to git?

2010-06-30 Thread Matt Di Pasquale
github rules!


[widgets] Draft agenda for 1 July 2010 voice conf

2010-06-30 Thread 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 http://www.w3.org/2008/webapps/track/issues/117 In 
Widget PC 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: 
http://lists.w3.org/Archives/Public/www-archive/2010Jun/0073.html
PR process: 
http://lists.w3.org/Archives/Public/www-archive/2010Jun/0075.html


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

a. Issue-116 http://www.w3.org/2008/webapps/track/issues/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:

http://www.w3.org/2008/webapps/track/actions/526 - Widget URI scheme: 
define the widget *URI* syntax in terms of RFC 3986


http://www.w3.org/2008/webapps/track/actions/551 - 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




Fwd: [whatwg] what happened to sendAsBinary?

2010-06-30 Thread 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 toni.ruo...@iki.fi
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




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

2010-06-30 Thread Anne van Kesteren
On Wed, 30 Jun 2010 13:48:47 +0200, Olli Pettay olli.pet...@helsinki.fi  
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 toni.ruo...@iki.fi
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/



Re: [widgets] API - openURL security considerations

2010-06-30 Thread 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 art.bars...@nokia.com 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,
 http://www.gnucitizen.org/blog/ie-pwns-secondlife/.

 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,
 http://www.gnucitizen.org/blog/ie-pwns-secondlife/.


 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 t...@w3.org 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,
 http://www.gnucitizen.org/blog/ie-pwns-secondlife/.


 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 with window.open() in browsers.

 Adam


 ** From: t...@w3.org
 Subject: Re: [widgets] API - 

Re: [widgets] API - openURL security considerations

2010-06-30 Thread 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 a 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 art.bars...@nokia.com 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,
 http://www.gnucitizen.org/blog/ie-pwns-secondlife/.
 
 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,
 http://www.gnucitizen.org/blog/ie-pwns-secondlife/.
 
 
 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 t...@w3.org 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,
 http://www.gnucitizen.org/blog/ie-pwns-secondlife/.
 
 
 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 

Re: [IndexedDB] IDBEvent and Event

2010-06-30 Thread Andrei Popescu
On Sat, Jun 26, 2010 at 12:41 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Fri, Jun 25, 2010 at 2:20 PM, Shawn Wilsher sdwi...@mozilla.com 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



OMTP BONDI 1.11 errata release

2010-06-30 Thread 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 

 



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

2010-06-30 Thread 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.



Re: [IndexedDB] IDBEvent and Event

2010-06-30 Thread 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


Re: BlobWriter simplification/split

2010-06-30 Thread Jonas Sicking
On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane er...@google.com 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: BlobWriter simplification/split

2010-06-30 Thread Eric Uhrhane
On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking jo...@sicking.cc wrote:
 On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane er...@google.com 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

2010-06-30 Thread Michael Nordman
On Wed, Jun 30, 2010 at 10:29 AM, Eric Uhrhane er...@google.com wrote:

 On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking jo...@sicking.cc wrote:
  On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane er...@google.com 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.


[Work in Progress on Web Notification Working Group

2010-06-30 Thread 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: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

2010-06-30 Thread 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



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

2010-06-30 Thread 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 a...@mozilla.com 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

2010-06-30 Thread 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 a...@mozilla.com 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




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

2010-06-30 Thread 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: [IndexedDB] Should .add/.put/.update throw when called in read-only transaction?

2010-06-30 Thread Jeremy Orlow
On Thu, Jul 1, 2010 at 11:17 AM, Jonas Sicking jo...@sicking.cc 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




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

2010-06-30 Thread Jonas Sicking
On Wed, Jun 30, 2010 at 6:42 PM, Jeremy Orlow jor...@chromium.org wrote:
 On Thu, Jul 1, 2010 at 11:17 AM, Jonas Sicking jo...@sicking.cc 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 check.

 This also will limit what can be done on a background thread.  For example,
 an implementation couldn't do 

[IndexedDB] .value of no-duplicate cursors

2010-06-30 Thread 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: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

2010-06-30 Thread 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 video/ 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




LCWD comments

2010-06-30 Thread 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 URI fragments is not allowed 

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

2010-06-30 Thread 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 jo...@sicking.cc wrote:

 On Wed, Jun 30, 2010 at 6:42 PM, Jeremy Orlow jor...@chromium.org wrote:
  On Thu, Jul 1, 2010 at 11:17 AM, Jonas Sicking jo...@sicking.cc 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 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).  

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

2010-06-30 Thread Jeremy Orlow
On Thu, Jul 1, 2010 at 12:07 PM, Jonas Sicking jo...@sicking.cc 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