Re: [WebSQLDatabase] Adding a vacuum() call

[João Eiras]

On Fri, 05 Mar 2010 03:22:00 +0100, Dumitru Daniliuc   
wrote:



Hi,

We (Chromium) would like to add a vacuum() call on the Database object.


[...]

I would argue about having something a bit more generic for naming like  
"defragment()".


I don't see how the callbacks are useful though. Vacuum works  
transparently, its effects are not visible, and what should the page do in  
case of error ?


Given that an operation like vacuum would be disk IO intensive, would it  
be good to give the webpage control over a feature that can have  
significant performance concerns ?
While computers benefit from good file IO performance, that's not quite  
true in many mobile devices. So, the API would be more like an hint ? How  
can the webpage know the level of fragmentation of the data file ?


Sqlite supports incremental vacuum http://www.sqlite.org/pragma.html so  
this kind of feature should be left for sqlite to handle for itself.

[WebSQLDatabase] Adding a vacuum() call

[Dumitru Daniliuc]

Hi,

We (Chromium) would like to add a vacuum() call on the Database object. The
idea is to allow the SQL engine to vacuum/compress/clean-up/do some
potentially expensive maintenance work on the respective database. In
SQLite's case, in particular, the vacuum() call would issue a VACUUM command
(which cannot run in a transaction, hence the web app developers do not have
access to it currently), which would make SQLite compact the database by
reusing the empty space on fragmented pages. We think this call is
necessary, because fragmented databases could lead to apps prematurely
reaching their quota limits.

Letting the UAs deal with this problem is not always an option. For example,
big apps like Gmail could always be "on" (loaded as soon as the browser
comes up and closed only when the browser shuts down), which means the UAs
would never have an opportunity to clean-up/compact the databases of those
apps without blocking them. In these cases, we believe the apps should be
responsible (and should have the opportunity) to clean up their own
databases when they feel that it is the best time to do so.

So we were wondering if it makes sense to add this call to the
WebSQLDatabases spec too.

The call would look like this:

interface Database {
  // the methods and properties currently in the spec
  void vacuum(in optional SQLVacuumErrorCallback errorCallback, in optional
SQLVoidCallback successCallback);
};

[Callback=FunctionOnly, NoInterfaceObject]
interface SQLVacuumErrorCallback {
  void handleEvent(in SQLError error);
};

And the steps would be the following:

   1. If vacuum() is called inside a transaction on the same database, jump
   to the "in case of error" steps below.
   2. Queue a task to vacuum, compress, clean-up or do any other necessary
   maintenance work on the given database.
   3. If the operation succeeds and a successCallback is provided, queue a
   task to invoke the successCallback.
   4. If the clean-up operation fails in any way, jump to the "in case of
   error" steps below.

In case of error:

   1. In an errorCallback is provided, queue a task to invoke the
   errorCallback.


Thanks,
Dumi

RE: [widgets] dir and span elements

[Richard Ishida]

Hi Marcos,

Thanks for your quick work on this.

I have a few comments. Hope they are helpful...

[1] 7.16. The span Element
http://dev.w3.org/2006/waf/widgets/#the-span-element 
There may be cases where span is also used to support xml:lang (not just dir).

[2] same section
I think the example could be improved by having something inside the span with 
punctuation (eg. exclamation mark) or such, and maybe the description should be 
in English - otherwise you'd probably want to put the dir on the widget tag and 
have English in the span.  Should I try to find another example ?


[3] same section
"it allows authors to override the Unicode bidirectional algorithm by 
explicitly specifying a direction override, as specified in [BIDI]."

There is no link on [BIDI], and there is no [BIDI] reference at the bottom of 
the page.

[4] same text
"it allows authors to override the Unicode bidirectional algorithm by 
explicitly specifying a direction override, as specified in [BIDI]."
=> 
"it allows authors to set the base direction for the Unicode bidirectional 
algorithm, as specified in [BIDI]."

I propose this change because the dir attribute as you define it doesn't have 
the rlo and lro values that would mean 'override', it has only ltr and rtl, 
which define the base direction.  I don't know if the 'as specified in...' bit 
is still relevant, since I don't know what that refers to.


[5] dir attribute
http://dev.w3.org/2006/waf/widgets/#global-attributes

Any reason that you don't specify rlo and lro values recommend in the ITS spec? 
 (They aren't use much, but I was wondering whether there was a particular 
reason that they aren't included.)


[6] same section
"An empty value of dir is used on an element B to override a specification of 
dir on an enclosing element A, without specifying another direction. Within B, 
it is considered that there is no directional information available, just as if 
dir had not been specified on B or any of its ancestors (see fourth example 
below)."

We discussed this during the i18n telecon.  We think having an empty value is a 
little odd, given that the direction has to be either ltr or rtl.  (For 
instance, it has no real effect or meaning in the final example below this text 
that we can detect.) We also think that is may cause some unintended problems 
for embedded text by creating inappropriate embeddings. We suspect that what 
you really need is something that we are about to propose for HTML5 (in a 
working draft that should hopefully be published as FPWD today), ie. a bdi 
attribute (bidi isolate).  It will be a little while before that is a stable 
document, however. 

In the meantime, our suggestion is that you drop the empty value for dir, and 
revisit this in a later version of the spec.



[7] same section, examples
The first example looks a little out of kilter wrt markup. (if you need help to 
sort it out just shout)  
Who provided the Persian translations? (I'd like to suggest some alternative 
examples, but I can't translate into Persian.)


I hope those comments are helpful.

RI


Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/




> -Original Message-
> From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
> requ...@w3.org] On Behalf Of Marcos Caceres
> Sent: 26 February 2010 17:45
> To: public-webapps
> Cc: public-i18n-c...@w3.org
> Subject: [widgets] dir and span elements
> 
> Hi i18n WG,
> I've added the dir attribute and span elements to the Widgets P&C
> Specification, as well as a bunch of examples (which are wrong, so I
> would really appreciate some help with these!).
> 
> The dir attribute is specified here:
> http://dev.w3.org/2006/waf/widgets/#global-attributes
> 
> The span element is specified here:
> http://dev.w3.org/2006/waf/widgets/#the-span-element
> 
> The processing step that defers to the yet to be written [WIDGET-BIDI]
> specification is defined here:
> http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content
> 
> The specification makes it mandatory that a user agent implement the
> WIDGET-BIDI spec:
> 
> "A user agent is an implementation of this specification that also
> supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS-BIDI],
> and [ZIP]..."
> 
> We would appreciate your review and any assistance you can provide.
> In particular, we would appreciate your guidance into what would go
> into the Widgets Bidi specification (i.e., how processing is done for
> dir and span). At the moment, we only have the following text for such
> a specification (based on HTML5's bdo element):
> 
> [[
> If an element has the dir attribute set to the exact value ltr, then
> for the purposes of the bidi algorithm, the user agent must act as if
> there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of
> the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of
> the
> element.
> 
> If the element has the d

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Nikunj Mehta]

On Mar 4, 2010, at 10:55 AM, Kris Zyp wrote:


On 3/4/2010 11:46 AM, Nikunj Mehta wrote:
>
 > On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:
 >
 >>
 >> On 3/4/2010 11:08 AM, Aaron Boodman wrote:
 > [snip]
 >>>
 >>> * There is nothing preventing JS authors from implementing a
 >>> promise-style API on top of IndexedDB, if that is what they
 >>> want to do.
 >>>
 >> Yes, you can always make an API harder to use so that JS authors
 >> have more they can do with it ;).
 >
 > You will agree that we don't want to wait for one style of
 > promises to win out over others before IndexedDB can be made
 > available to programmers. Till the soil and let a thousand flowers
 > bloom.

The IndexedDB spec isn't and can't just sit back and not define the
asynchronous interface. Like it or not, IndexedDB has defined a
promise-like entity with the |DBRequest| interface. Why is inventing a
new (and somewhat ugly) flower better than designing based on the many
flowers that have already bloomed?


I meant to say that the IndexedDB spec should be updated to use a  
model that supports promises. If the current one is not adequate then,  
by all means, let's make it. However, we don't need a full-fledged  
promises in IndexedDB. I hope you agree this time.

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 3/4/2010 11:46 AM, Nikunj Mehta wrote:
>
> On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:
>
>>
>> On 3/4/2010 11:08 AM, Aaron Boodman wrote:
> [snip]
>>>
>>> * There is nothing preventing JS authors from implementing a
>>> promise-style API on top of IndexedDB, if that is what they
>>> want to do.
>>>
>> Yes, you can always make an API harder to use so that JS authors
>> have more they can do with it ;).
>
> You will agree that we don't want to wait for one style of
> promises to win out over others before IndexedDB can be made
> available to programmers. Till the soil and let a thousand flowers
> bloom.

The IndexedDB spec isn't and can't just sit back and not define the
asynchronous interface. Like it or not, IndexedDB has defined a
promise-like entity with the |DBRequest| interface. Why is inventing a
new (and somewhat ugly) flower better than designing based on the many
flowers that have already bloomed?

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkuQAiUACgkQ9VpNnHc4zAzZkgCeIjAVz56S3sR5BeKt8lZPGMJo
6rYAoJ4x4WJN9W9LhdXkbbJaT94A8/om
=oJbA
-END PGP SIGNATURE-

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Thu, Mar 4, 2010 at 6:46 PM, Nikunj Mehta  wrote:

>
> On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:
>
>
>> On 3/4/2010 11:08 AM, Aaron Boodman wrote:
>>
>>> On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow 
>>> wrote:
>>>
 On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp 
 wrote:

>
> * Use promises for async interfaces - In server side
> JavaScript, most projects are moving towards using promises for
> asynchronous interfaces instead of trying to define the
> specific callback parameters for each interface. I believe the
> advantages of using promises over callbacks are pretty well
> understood in terms of decoupling async semantics from
> interface definitions, and improving encapsulation of concerns.
> For the indexed database API this would mean that sync and
> async interfaces could essentially look the same except sync
> would return completed values and async would return promises.
> I realize that defining a promise interface would have
> implications beyond the indexed database API, as the goal of
> promises is to provide a consistent interface for asynchronous
> interaction across components, but perhaps this would be a good
> time for the W3C to define such an API. It seems like the
> indexed database API would be a perfect interface to leverage
> promises. If you are interested in proposal, there is one from
> CommonJS here [1] (the get() and call() wouldn't apply here).
> With this interface, a promise.then(callback, errorHandler)
> function is the only function a promise would need to provide.
>
> [1] http://wiki.commonjs.org/wiki/Promises
>

 Very interesting.  The general concept seems promising and fairly
 flexible. You can easily code in a similar style to normal
 async/callback semantics, but it seems like you have a lot more
 flexibility.  I do have a few questions though. Are there any
 good examples of these used in the wild that you can point me
 towards?  I used my imagination for prototyping up some examples,
 but it'd be great to see some real examples + be able to see the
 exact semantics used in those implementations. I see that you can
 supply an error handling callback to .then(), but does that only
 apply to the one operation?  I could easily imagine emulating
 try/catch type semantics and have errors continue down the line
 of .then's until someone handles it.  It might even make sense to
 allow the error handlers to re-raise (i.e. allow to bubble)
 errors so that later routines would get them as well.  Maybe
 you'd even want it to bubble by default? What have other
 implementations done with this stuff?  What is the most robust
 and least cumbersome for typical applications?  (And, in te
 complete absence of real experience, are there any expert
 opinions on what might work?) Overall this seems fairly promising
 and not that hard to implement.  Do others see pitfalls that I'm
 missing? J

>>>
>>> I disagree that IndexedDB should use promises, for several
>>> reasons:
>>>
>>> * Promises are only really useful when they are used ubiquitously
>>> throughout the platform, so that you can pass them around like
>>> references. In libraries like Dojo, MochiKit, and Twisted, this is
>>> exactly the situation. But in the web platform, this would be the
>>> first such API. Without places to pass a promise to, all you
>>> really have is a lot of additional complexity.
>>>
>>
>> I certainly agree that promises are more useful when used
>> ubiquitously. However, promises have many advantages besides just
>> being a common interface for asynchronous operations, including
>> interface simplicity, composibility, and separation of concerns. But,
>> your point about this being the first such API is really important. If
>> we are going to use promises in the IndexedDB, I think they should the
>> webapps group should be looking at them beyond the scope of just the
>> IndexedDB API, and how they could be used in other APIs, such that
>> common interface advantage could be realized. Looking at the broad
>> perspective is key here.
>>
>
> In general, IndexedDB has taken an approach of leaving ease of programming
> to libraries. There seems to be a good case to build libraries to make
> asynchronous programming with IndexedDB easier through the use of such
> mechanisms as promises. In fact, IndexedDB might be yet another area for
> libraries to slug it out.
>
>
>
>>> * ISTM that the entire space is still evolving quite rapidly. Many
>>> JavaScript libraries have implemented a form of this, and this
>>> proposal is also slightly different from any of them. I think it
>>> is premature to have browsers implement this while library authors
>>> are still hashing out best practice. Once it is in browsers, it's
>>> forever.
>>>
>> Promises have been around for a number of years, we already have a lot
>> of experien

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Nikunj Mehta]

On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:



On 3/4/2010 11:08 AM, Aaron Boodman wrote:

On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow 
wrote:

On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp 
wrote:


* Use promises for async interfaces - In server side
JavaScript, most projects are moving towards using promises for
asynchronous interfaces instead of trying to define the
specific callback parameters for each interface. I believe the
advantages of using promises over callbacks are pretty well
understood in terms of decoupling async semantics from
interface definitions, and improving encapsulation of concerns.
For the indexed database API this would mean that sync and
async interfaces could essentially look the same except sync
would return completed values and async would return promises.
I realize that defining a promise interface would have
implications beyond the indexed database API, as the goal of
promises is to provide a consistent interface for asynchronous
interaction across components, but perhaps this would be a good
time for the W3C to define such an API. It seems like the
indexed database API would be a perfect interface to leverage
promises. If you are interested in proposal, there is one from
CommonJS here [1] (the get() and call() wouldn't apply here).
With this interface, a promise.then(callback, errorHandler)
function is the only function a promise would need to provide.

[1] http://wiki.commonjs.org/wiki/Promises


Very interesting.  The general concept seems promising and fairly
flexible. You can easily code in a similar style to normal
async/callback semantics, but it seems like you have a lot more
flexibility.  I do have a few questions though. Are there any
good examples of these used in the wild that you can point me
towards?  I used my imagination for prototyping up some examples,
but it'd be great to see some real examples + be able to see the
exact semantics used in those implementations. I see that you can
supply an error handling callback to .then(), but does that only
apply to the one operation?  I could easily imagine emulating
try/catch type semantics and have errors continue down the line
of .then's until someone handles it.  It might even make sense to
allow the error handlers to re-raise (i.e. allow to bubble)
errors so that later routines would get them as well.  Maybe
you'd even want it to bubble by default? What have other
implementations done with this stuff?  What is the most robust
and least cumbersome for typical applications?  (And, in te
complete absence of real experience, are there any expert
opinions on what might work?) Overall this seems fairly promising
and not that hard to implement.  Do others see pitfalls that I'm
missing? J


I disagree that IndexedDB should use promises, for several
reasons:

* Promises are only really useful when they are used ubiquitously
throughout the platform, so that you can pass them around like
references. In libraries like Dojo, MochiKit, and Twisted, this is
exactly the situation. But in the web platform, this would be the
first such API. Without places to pass a promise to, all you
really have is a lot of additional complexity.


I certainly agree that promises are more useful when used
ubiquitously. However, promises have many advantages besides just
being a common interface for asynchronous operations, including
interface simplicity, composibility, and separation of concerns. But,
your point about this being the first such API is really important. If
we are going to use promises in the IndexedDB, I think they should the
webapps group should be looking at them beyond the scope of just the
IndexedDB API, and how they could be used in other APIs, such that
common interface advantage could be realized. Looking at the broad
perspective is key here.


In general, IndexedDB has taken an approach of leaving ease of  
programming to libraries. There seems to be a good case to build  
libraries to make asynchronous programming with IndexedDB easier  
through the use of such mechanisms as promises. In fact, IndexedDB  
might be yet another area for libraries to slug it out.




* ISTM that the entire space is still evolving quite rapidly. Many
JavaScript libraries have implemented a form of this, and this
proposal is also slightly different from any of them. I think it
is premature to have browsers implement this while library authors
are still hashing out best practice. Once it is in browsers, it's
forever.

Promises have been around for a number of years, we already have a lot
of experience to draw from, this isn't exactly a brand new idea,
promises are a well-established concept. The CommonJS proposal is
nothing ground breaking, it is more based on the culmination of ideas
of Dojo, ref_send and others. It is also worth noting that a number of
JS libraries have expressed interest in moving towards the CommonJS
promise proposal, and Dojo will probably support them in 1.5.


I feel that we should avoid taking a general position on prom

[widgets] IESG Approved Media Type application/widget

[Arthur Barstow]

FYI (subject says it all).

Begin forwarded message:


From: ext Alexey Melnikov 
Date: March 4, 2010 1:19:33 PM EST
To: Philippe Le Hegaret 
Cc: "i...@ietf.org" , "marc...@opera.com"  
, "public-ietf-...@w3.org" w...@w3.org>, Dan Connolly 
Subject: Re: Requesting IESG Approval for the Media Type  
application/widget

Archived-At: 

Philippe Le Hegaret wrote:


Dear IESG participants,

This message is to request approval for the registration of the media
type "application/widget", as described in an appendix of "Widget
Packaging and Configuration":

http://www.w3.org/TR/widgets/#media-type-registration-for- 
applicationw


This message follows the procedure described in the Media Type
Specifications and Registration Procedures, section 5.2, "IESG
Approval" [1]. The proposed media type were sent for preliminary
community review on October 28, 2008:

http://www.alvestrand.no/pipermail/ietf-types/2009-October/ 
002275.html


No comments were received during the review period.

We believe the media type is now ready for IESG approval.


This was approved by IESG today. An official announcement should be  
sent

out early next week.


Thank you,

Philippe

[1] http://www.ietf.org/rfc/rfc4288.txt






--
IETF Application Area Director, 
Internet Messaging Team Lead, 
JID: same as my email address

Re: Event handlers - Pointer Devices

[Charles Pritchard]

> On the main (or more useful) point perhaps, I think the distinction
> between a device's internal features, its peripherals as attached
> features, and more abstracted (even remote) resources is still very 
blurry

> between Webapps and DAP.
...
> Bryan Sullivan | AT&T

Perhaps the "System Information and Events API" section of the DAP 
charter should be two separate items. It seems to me that Events are the 
cause of the confusion here; and they are complex. The charter summary 
doesn't mention that most of the protocol APIs could trigger events.


For instance:

Many Cameras will be supporting simple image recognition of 2d barcodes; 
onbarcode() would, for instance, be an event. such an event would likely 
be in the DAP charter, not in the WebApps charter (am I wrong?). 
Additional events would encompass the current device APIs ( 
oncamerastart, ontaskadded, onnetworkunreachable, etc ).


The DAP really seems quite restricted to PIMs, which is surprising. 
Where do measurement accessories such as accelerometer, thermometer, 
compass, and other measurement services fit?


> From: Doug Schepers
...
> DAP is not focused on user-input devices, more on things like cameras,
> calendars, etc. available on the local device.
>
> I am concerned that it may not be fruitful, and may be
> counterproductive, for us to start speculating on this list about IPR.
> Let's keep the discussion on technical matters, please.
...
> However, use cases and requirements would be appropriate to discuss, and
> this should help frame a successful outcome for this spec.
...
> [1] http://www.w3.org/2009/05/DeviceAPICharter

Well, I'd like to speculate a little: touch is not patented but "gesture 
recognition" is. Working within that framework gives us a firm scope: 
"onpressurechange" is a touch event, "onPsychicRaysOfIntent" is 
something that can be left up to a mechanism detailed by the Device API 
group. Gestures may well belong to a persons personal device profile.


I've seen requests for "ondeviceshake", "onpinch", but I fear that 
implementations might run afoul of existing IP. There are also better 
names, that target their typical functionality: "onpinch" is often used 
to trigger a zoom command; "onzoom" (or a borrowing from SVG), would 
allow for the same functionality, without suggesting a gesture 
recognition system.


I realize that it'd be far easier to write some applications if these 
high level APIs were part of every implementation, but I think they are 
too risky. What is a "pinch", what threshold should a "shake" have? 
These are details to be left to individual implementations. Let's 
sidestep the issue early.



-Charles

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 3/4/2010 11:08 AM, Aaron Boodman wrote:
> On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow 
> wrote:
>> On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp 
>> wrote:
>>>
>>> * Use promises for async interfaces - In server side
>>> JavaScript, most projects are moving towards using promises for
>>> asynchronous interfaces instead of trying to define the
>>> specific callback parameters for each interface. I believe the
>>> advantages of using promises over callbacks are pretty well
>>> understood in terms of decoupling async semantics from
>>> interface definitions, and improving encapsulation of concerns.
>>> For the indexed database API this would mean that sync and
>>> async interfaces could essentially look the same except sync
>>> would return completed values and async would return promises.
>>> I realize that defining a promise interface would have
>>> implications beyond the indexed database API, as the goal of
>>> promises is to provide a consistent interface for asynchronous
>>> interaction across components, but perhaps this would be a good
>>> time for the W3C to define such an API. It seems like the
>>> indexed database API would be a perfect interface to leverage
>>> promises. If you are interested in proposal, there is one from
>>> CommonJS here [1] (the get() and call() wouldn't apply here).
>>> With this interface, a promise.then(callback, errorHandler)
>>> function is the only function a promise would need to provide.
>>>
>>> [1] http://wiki.commonjs.org/wiki/Promises
>>
>> Very interesting.  The general concept seems promising and fairly
>> flexible. You can easily code in a similar style to normal
>> async/callback semantics, but it seems like you have a lot more
>> flexibility.  I do have a few questions though. Are there any
>> good examples of these used in the wild that you can point me
>> towards?  I used my imagination for prototyping up some examples,
>> but it'd be great to see some real examples + be able to see the
>> exact semantics used in those implementations. I see that you can
>> supply an error handling callback to .then(), but does that only
>> apply to the one operation?  I could easily imagine emulating
>> try/catch type semantics and have errors continue down the line
>> of .then's until someone handles it.  It might even make sense to
>> allow the error handlers to re-raise (i.e. allow to bubble)
>> errors so that later routines would get them as well.  Maybe
>> you'd even want it to bubble by default? What have other
>> implementations done with this stuff?  What is the most robust
>> and least cumbersome for typical applications?  (And, in te
>> complete absence of real experience, are there any expert
>> opinions on what might work?) Overall this seems fairly promising
>> and not that hard to implement.  Do others see pitfalls that I'm
>> missing? J
>
> I disagree that IndexedDB should use promises, for several
> reasons:
>
> * Promises are only really useful when they are used ubiquitously
> throughout the platform, so that you can pass them around like
> references. In libraries like Dojo, MochiKit, and Twisted, this is
> exactly the situation. But in the web platform, this would be the
> first such API. Without places to pass a promise to, all you
> really have is a lot of additional complexity.

I certainly agree that promises are more useful when used
ubiquitously. However, promises have many advantages besides just
being a common interface for asynchronous operations, including
interface simplicity, composibility, and separation of concerns. But,
your point about this being the first such API is really important. If
we are going to use promises in the IndexedDB, I think they should the
webapps group should be looking at them beyond the scope of just the
IndexedDB API, and how they could be used in other APIs, such that
common interface advantage could be realized. Looking at the broad
perspective is key here.
>
> * ISTM that the entire space is still evolving quite rapidly. Many
> JavaScript libraries have implemented a form of this, and this
> proposal is also slightly different from any of them. I think it
> is premature to have browsers implement this while library authors
> are still hashing out best practice. Once it is in browsers, it's
> forever.
Promises have been around for a number of years, we already have a lot
of experience to draw from, this isn't exactly a brand new idea,
promises are a well-established concept. The CommonJS proposal is
nothing ground breaking, it is more based on the culmination of ideas
of Dojo, ref_send and others. It is also worth noting that a number of
JS libraries have expressed interest in moving towards the CommonJS
promise proposal, and Dojo will probably support them in 1.5.
>
> * There is nothing preventing JS authors from implementing a
> promise-style API on top of IndexedDB, if that is what they want
> to do.
>
Yes, you can always make an API harder to use so that JS aut

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Thu, Mar 4, 2010 at 5:46 PM, Kris Zyp  wrote:

>  -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 3/4/2010 10:35 AM, Mark S. Miller wrote:
> > On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow  >  > wrote:
> >
> > You are quite right!  I misunderstood how this part of promises
> > worked.
> >
> > Is there excitement about speccing promises in general?
> >
> >
> > Yes. The starting point for a lot of the commonjs promises work is
> > Tyler's ref_send promise library, documented at
> > .
> The commonjs work
> > got more complicated than this in order to try to accommodate
> > legacy deferred-based usage patterns within the same framework.
> > While it may have helped adoption within the commonjs community,
> > IMO this extra complexity should not be in any standard promise
> > spec. Caja implements Tyler's spec without the extra complexity,
> > and we're quite happy with it.
> >
> > I hope to work with Tyler and others to propose this to the
> > EcmaScript committee as part of a more general proposal for a
> > communicating-event-loops concurrency and distribution framework
> > for future EcmaScript. Don't hold your breath though, this is not
> > yet even an EcmaScript strawman. Neither is there any general
> > consensus on the EcmaScript committee that EcmaScript should be
> > extended in these directions. In the meantime, I suggest just using
> > Tyler's ref_send and web_send libraries.
>
>
> It would be great if promises become first class, but obviously the
> IndexedDB specification can't be dependent on someone's JS library.
>
> >
> >
> >
> > If not, it seems a little odd to spec such a powerful mechanism
> > into just IndexedDBand it might be best to spec the simplified
> > version of .then(): .then() will return undefined,
> > onsuccess/onerror's return values will be swallowed, and any thrown
> > exceptions will be thrown.
> >
> > This should make it easy to make IndexedDB support full blown
> > promises if/whenever they're specced.  (It's not clear to me
> > whether UA support for them would offer enough advantages to
> > warrant it.)
> >
> >
> > Note that ref_send exposes the .then() style functionality as a
> > static .when() method on Q rather than an instance .then() method
> > on promises. This is important, as it 1) allows resolved values to
> > be used where a promise is expected, and 2) it protects the caller
> > from interleavings happening during their Q.when() call, even if
> > the alleged promise they are operating on is something else.
>

Thanks a lot for your feedback!  This is very valuable and definitely
provided some food for thought.  I started working on a rambly email about
the pro's and cons of "when" when I saw Kris's response.


> The .then() function is in no way intended to be a replacement for a
> static .when() function. In contrast to ref_send, having promises
> defined by having a .then() function is in lieu of ref_send's
> definition of a promise where the promise is a function that must be
> called:
> promise("WHEN", callback, errback);
> This group can consider it an API like this, but I don't think that
> IndexedDB or any other W3C API would want to define promises in that
> way, as it is pretty awkward. Using .then() based promises in no way
> precludes the use of Q.when() implementations which meet both your
> criteria for safe operation. However, these can easily be implemented
> in JS, and I don't think the IndexedDB API needs to worry about such
> promise libraries.
>

Which is basically what I had arrived at in my mind as well.

It'll definitely be interesting to see how the EMCAScript side of promises
shapes up.  But in the mean time, I think the simpler version that we've
been discussing will be a good balance of features but minimized API surface
area...and keeping chances high that what ends up being standardized would
fit in well with the API.

At this point, I feel fairly confident that using a scaled down version of
promises would work well in IndexedDB.  But, at the same time, a callback
based API would be much more standard and it wouldn't be that hard for
someone to build a promise based library around IndexedDB.  Nikunj, Pablo,
Mozilla, etc...what do you think is the best way forward here?  Should we
give scaled back promises a shot?  Or should we just go with a callback
based approach?

J


Summary of what I'm currently thinking we should do, if we go with a
"Promises" type async API:

Each async function would return a promise.  A promise has one method:
".then()".  Then takes up to two callbacks. The first is onsuccess.  The
second is onerror.  You can call .then() before and after the async call has
finished--in fact, there's no way to know for sure whether it has finished
before you call .then() (but that's fine).  If you pass in garbage to the
callbacks, it'll throw an exception, but null/undefined and omitting them

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Aaron Boodman]

On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow  wrote:
> On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp  wrote:
>>
>> * Use promises for async interfaces - In server side JavaScript, most
>> projects are moving towards using promises for asynchronous interfaces
>> instead of trying to define the specific callback parameters for each
>> interface. I believe the advantages of using promises over callbacks
>> are pretty well understood in terms of decoupling async semantics from
>> interface definitions, and improving encapsulation of concerns. For
>> the indexed database API this would mean that sync and async
>> interfaces could essentially look the same except sync would return
>> completed values and async would return promises. I realize that
>> defining a promise interface would have implications beyond the
>> indexed database API, as the goal of promises is to provide a
>> consistent interface for asynchronous interaction across components,
>> but perhaps this would be a good time for the W3C to define such an
>> API. It seems like the indexed database API would be a perfect
>> interface to leverage promises. If you are interested in proposal,
>> there is one from CommonJS here [1] (the get() and call() wouldn't
>> apply here). With this interface, a promise.then(callback,
>> errorHandler) function is the only function a promise would need to
>> provide.
>>
>> [1] http://wiki.commonjs.org/wiki/Promises
>
> Very interesting.  The general concept seems promising and fairly flexible.
>  You can easily code in a similar style to normal async/callback semantics,
> but it seems like you have a lot more flexibility.  I do have a few
> questions though.
> Are there any good examples of these used in the wild that you can point me
> towards?  I used my imagination for prototyping up some examples, but it'd
> be great to see some real examples + be able to see the exact semantics used
> in those implementations.
> I see that you can supply an error handling callback to .then(), but does
> that only apply to the one operation?  I could easily imagine emulating
> try/catch type semantics and have errors continue down the line of .then's
> until someone handles it.  It might even make sense to allow the error
> handlers to re-raise (i.e. allow to bubble) errors so that later routines
> would get them as well.  Maybe you'd even want it to bubble by default?
>  What have other implementations done with this stuff?  What is the most
> robust and least cumbersome for typical applications?  (And, in te complete
> absence of real experience, are there any expert opinions on what might
> work?)
> Overall this seems fairly promising and not that hard to implement.  Do
> others see pitfalls that I'm missing?
> J

I disagree that IndexedDB should use promises, for several reasons:

* Promises are only really useful when they are used ubiquitously
throughout the platform, so that you can pass them around like
references. In libraries like Dojo, MochiKit, and Twisted, this is
exactly the situation. But in the web platform, this would be the
first such API. Without places to pass a promise to, all you really
have is a lot of additional complexity.

* ISTM that the entire space is still evolving quite rapidly. Many
JavaScript libraries have implemented a form of this, and this
proposal is also slightly different from any of them. I think it is
premature to have browsers implement this while library authors are
still hashing out best practice. Once it is in browsers, it's forever.

* There is nothing preventing JS authors from implementing a
promise-style API on top of IndexedDB, if that is what they want to
do.

- a

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 3/4/2010 10:35 AM, Mark S. Miller wrote:
> On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow  > wrote:
>
> You are quite right!  I misunderstood how this part of promises
> worked.
>
> Is there excitement about speccing promises in general?
>
>
> Yes. The starting point for a lot of the commonjs promises work is
> Tyler's ref_send promise library, documented at
> . The commonjs work
> got more complicated than this in order to try to accommodate
> legacy deferred-based usage patterns within the same framework.
> While it may have helped adoption within the commonjs community,
> IMO this extra complexity should not be in any standard promise
> spec. Caja implements Tyler's spec without the extra complexity,
> and we're quite happy with it.
>
> I hope to work with Tyler and others to propose this to the
> EcmaScript committee as part of a more general proposal for a
> communicating-event-loops concurrency and distribution framework
> for future EcmaScript. Don't hold your breath though, this is not
> yet even an EcmaScript strawman. Neither is there any general
> consensus on the EcmaScript committee that EcmaScript should be
> extended in these directions. In the meantime, I suggest just using
> Tyler's ref_send and web_send libraries.

It would be great if promises become first class, but obviously the
IndexedDB specification can't be dependent on someone's JS library.
>
>
>
> If not, it seems a little odd to spec such a powerful mechanism
> into just IndexedDBand it might be best to spec the simplified
> version of .then(): .then() will return undefined,
> onsuccess/onerror's return values will be swallowed, and any thrown
> exceptions will be thrown.
>
> This should make it easy to make IndexedDB support full blown
> promises if/whenever they're specced.  (It's not clear to me
> whether UA support for them would offer enough advantages to
> warrant it.)
>
>
> Note that ref_send exposes the .then() style functionality as a
> static .when() method on Q rather than an instance .then() method
> on promises. This is important, as it 1) allows resolved values to
> be used where a promise is expected, and 2) it protects the caller
> from interleavings happening during their Q.when() call, even if
> the alleged promise they are operating on is something else.

The .then() function is in no way intended to be a replacement for a
static .when() function. In contrast to ref_send, having promises
defined by having a .then() function is in lieu of ref_send's
definition of a promise where the promise is a function that must be
called:
promise("WHEN", callback, errback);
This group can consider it an API like this, but I don't think that
IndexedDB or any other W3C API would want to define promises in that
way, as it is pretty awkward. Using .then() based promises in no way
precludes the use of Q.when() implementations which meet both your
criteria for safe operation. However, these can easily be implemented
in JS, and I don't think the IndexedDB API needs to worry about such
promise libraries.

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkuP8f0ACgkQ9VpNnHc4zAwm9gCfajBUy0PZpaxvSctlorVeYIsK
yQwAnAwtSd6BWPbpOOJTniZcojmNFQtw
=GHjA
-END PGP SIGNATURE-

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Mark S. Miller]

On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow  wrote:

> You are quite right!  I misunderstood how this part of promises worked.
>
> Is there excitement about speccing promises in general?
>

Yes. The starting point for a lot of the commonjs promises work is Tyler's
ref_send promise library, documented at <
http://waterken.sourceforge.net/web_send/#Q>. The commonjs work got more
complicated than this in order to try to accommodate legacy deferred-based
usage patterns within the same framework. While it may have helped adoption
within the commonjs community, IMO this extra complexity should not be in
any standard promise spec. Caja implements Tyler's spec without the extra
complexity, and we're quite happy with it.

I hope to work with Tyler and others to propose this to the EcmaScript
committee as part of a more general proposal for a communicating-event-loops
concurrency and distribution framework for future EcmaScript. Don't hold
your breath though, this is not yet even an EcmaScript strawman. Neither is
there any general consensus on the EcmaScript committee that EcmaScript
should be extended in these directions. In the meantime, I suggest just
using Tyler's ref_send and web_send libraries.



>  If not, it seems a little odd to spec such a powerful mechanism into just
> IndexedDBand it might be best to spec the simplified version of
> .then(): .then() will return undefined, onsuccess/onerror's return values
> will be swallowed, and any thrown exceptions will be thrown.
>
> This should make it easy to make IndexedDB support full blown promises
> if/whenever they're specced.  (It's not clear to me whether UA support for
> them would offer enough advantages to warrant it.)
>

Note that ref_send exposes the .then() style functionality as a static
.when() method on Q rather than an instance .then() method on promises. This
is important, as it 1) allows resolved values to be used where a promise is
expected, and 2) it protects the caller from interleavings happening during
their Q.when() call, even if the alleged promise they are operating on is
something else.




>
> It sounds like you're OK with such an approach, Kris?
>
> What do others think?
>
> J
>
>
>>  >
>> > > In terms of speccing, I'm not sure if we can get away with
>> > speccing
>> >
>> > > one promise interface or whether we'd need to create one for each
>> >
>> > > type of promise.
>> >
>> > Certainly the intent of promises is that there is exists only one
>> > generic promise interface that can be reused everywhere, at
>> > least from
>> > the JS perspective, not sure if the extra type constraints in IDL
>> > demand multiple interfaces to model promise's effectively
>> > parameterized generic type form.
>> >
>> >
>> > Unfortunately, I don't really know.  Before we try speccing it, I'll
>> > definitely see if any WebIDL experts have suggestions.
>> >
>> >
>> > Also, do we want to explicitly spec what happens in the following case?
>> >
>> > window.indexedDB.open(...).then(
>> > function(db) {  db.openObjectStore("a").then( function(os) {
>> > alert("Opened a"); } ) }
>> > ).then(
>> > function(db) { alert("Second db opened"); }
>> > );
>> >
>> > Clearly the first function(db) is called first.  But the question is
>> > whether it'd be a race of which alert is called first or whether the
>> > "Second db opened" alert should always be shown first (since clearly
>> > if the first is called, the second _can_ be fired immediately
>> > afterwards).
>> >
>> > I'm on the fence about whether it'd be useful to spec that the
>> > entire chain needs to be called one after the other before calling
>> > any other callbacks.  Does anyone have thoughts on whether this is
>> > useful or not?  If we do spec it to call the entire chain, then what
>> > happens if inside one of the callbacks, something is added to the
>> > chain (via another .then() call).
>> >
>> Specing the order of multiple events in the event loop seems like it
>> would be excessive burden on implementors, IMO.
>>
>> > I've been talking to a co-worker here who seems to know a decent
>> > amount about promises (as implemented in E) and some about differed
>> > (as implemented in Python's Twisted library).  From talking to him,
>> > it seems that my original suggestion for not handling exceptions
>> > thrown inside a .then() callback is the way to go.
>> >
>> > It seems as though promises put a lot of weight on composability and
>> > making it so that the order of .then() calls not mattering.  This
>> > means that you can then pass promises to other async interfaces and
>> > not have to worry about different timings leading to different
>> > results.  It also means that if you pass a promise into multiple
>> > consumers (say, javascript libraries) you don't need to worry about
>> > one using a promise in a way that screws up another.
>> >
>> > Differed seems to be more expressive and flexible.  For example,
>> > instead of doing this:
>> >
>> > w

Re: [widgets] Request for Comments: LCWD of Widget Access Request Policy spec; deadline 13-Jan-2010

[Marcos Caceres]

For the sake of the disposition of comments, I consider my comments 
disposed of (in a good way) :)


Kind regards,
Marcos

On 4/03/10 4:28 PM, Robin Berjon wrote:

Hi Marcos,

On Dec 21, 2009, at 16:06 , Marcos Caceres wrote:

An access request is a request made by an author to the user agent for
the ability to retrieve one or more network resources. The network
resources and author requests to access are identified using access
elements in the widget's configuration document.


I gots me confused by the second sentence, maybe change to:

"Requests by an author to access network resources can be identified
by the presence of access elements in the widget's configuration document."


Sounds just as confused to me. How about:

"Access element in the widget's configuration document express the author's requests 
to access network resources."

?


Good enough.


3. Conformance
This specification defines conformance criteria that apply to a single
product: user agents that implement the interfaces that it contains.


It's confusing to talk about "interfaces" here, though I understand
you are talking about interfaces in general terms. I would prefer if
the spec just said:

"This specification defines conformance criteria that apply to a single
product: user agents."

And a "user agent" be defined as "a software application that
implements this specification and the [WIDGETS] specification and it's
dependencies."


Okay.


A user agent enforces an access request policy. In the default policy,
a user agent must deny access to network resources external to the
widget by default, whether this access is requested through APIs (e.g.
XMLHttpRequest) or through markup (e.g. iframe, script, img).


i think you need to make it really clear that you've just defined the
"default policy" for a WUA. Please make it a sub-section or something.


A subsection seems overkill for a single sentence. I'll split it into its own 
paragraph and make sure it's a dfn.


Ok.


The exact rules defining which execution scope applies to network
resources loaded into a document running in the widget execution scope
depend on the language that is being used inside the the widget.


Typo: "the the"


Okay.



5. The access Element
Context in which this element may be used:


P&C uses "Context in which this element is used:". It would be nice if
this one said the same thing :)


Okay!


Great.


5.1 Attributes

origin
An IRI attribute that defines the specifics of the access request that
is requested.


"that is requested" seems tautological... and makes the sentence read
funny (and not "ha ha" funny.)


I'll make it "that is made".


"Additionally, an author can use the special value of U+002A ASTERISK (*):"


Okay.


This special value provides a means for an author to
request from the user agent unrestricted access to network resources.


Break here.


It's HAMMERTIME!


(Oh-oh-oh-oh-oh-oh-oh-oh-oh-oh-oh-oh)


Only the scheme and authority components can be present in the IRI
that this attribute contains ([URI], [RFC3987]).


I'm really sorry, I'm having a hard time parsing the above sentence.
At first, I thought it was related to the sentence about "*". Can you
change the order of these sentences above. Also, the "*" value is
pretty important, maybe it deserves it's own sub-section even if it
just contains one short paragraph. i'm sure people will come back
asking for clarification once we go to CR as to how it's supposed to
work.


I'll split and clarify.


subdomains
A boolean attribute that indicates whether or not the host component
part of the access request applies to subdomains of domain in the
origin attribute.


It should be clear that "subdomains" and "domain" here refers to
components of RFC-such-and-such, right?


Yup, adding a reference to RFC 1034.


The default value when this attribute is absent is
false, meaning that access to subdomains is not requested.


what does it means when I have:

http://foo.bar.woo.com"; subdomains="true"/>

Everything before "woo.com" is allowed, right? Maybe could be clear in
the spec for people like me :)


Err no, everything below foo.bar.woo.com. Maybe after reading RFC 1034 it'll be 
clearer?

"""
A domain is a subdomain of another domain if it
is contained within that domain.  This relationship can be tested by
seeing if the subdomain's name ends with the containing domain's name.
For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
"""


5.2 Usage example

This example contains multiple uses of the access element (not
contained in the same configuration as the last one would make the
others useless).


The above sentence doesn't tell me anything (that I can understand)
about the example. It be nice if it told me what I was looking at a
bit more. Maybe you need to break this up into multiple examples,
showing when it would be appropriate to use "*".


I'll clarify it somewhat (though it seems perfectly clear to me — it's several 
examples of the element!).


They presume that http

Re: [WARP] comment on subdomains

[Thomas Roessler]

1034 sounds like the appropriate normative reference for this sort of thing.
--
Thomas Roessler, W3C  







On 4 Mar 2010, at 15:51, Robin Berjon wrote:

> Hi Dom,
> 
> On Dec 10, 2009, at 16:51 , Dominique Hazael-Massieux wrote:
>> A quick comment after re-reading WARP at the invitation of Robin to DAP
>> [1]: I don’t think the notion of subdomain is well-defined; is w3.org a
>> subdomain of .org? is co a subdomain of co.uk? I assume they are in the
>> sense of the spec, but if that’s so, it doesn’t match the “street”
>> meaning of the word “subdomain”; this matters in particular in section 7
>> (rules for granting access), since this has an impact on how a user
>> agent decides to grant access to a network resource. Given that IP
>> addresses are allowed, the algorithm to determine if something is a
>> subdomain of another domain is as simple as looking to the last dot in
>> the authority component.
> 
> That's a fair point. Would referencing RFC 1034 in that section address your 
> concern? I would rather not have to define subdomain ourselves but rather 
> reuse what already exists!
> 
>> (kudos on the spec otherwise; I find it to be very crisp)
> 
> Thanks!
> 
> -- 
> Robin Berjon - http://berjon.com/
> 
> 
> 
> 
> 

Re: [WARP] comment on subdomains

[Robin Berjon]

On Mar 4, 2010, at 16:07 , Dominique Hazael-Massieux wrote:
> Le jeudi 04 mars 2010 à 15:51 +0100, Robin Berjon a écrit :
>> On Dec 10, 2009, at 16:51 , Dominique Hazael-Massieux wrote:
>>> A quick comment after re-reading WARP at the invitation of Robin to DAP
>>> [1]: I don’t think the notion of subdomain is well-defined; is w3.org a
>>> subdomain of .org? is co a subdomain of co.uk? I assume they are in the
>>> sense of the spec, but if that’s so, it doesn’t match the “street”
>>> meaning of the word “subdomain”; this matters in particular in section 7
>>> (rules for granting access), since this has an impact on how a user
>>> agent decides to grant access to a network resource. Given that IP
>>> addresses are allowed, the algorithm to determine if something is a
>>> subdomain of another domain is as simple as looking to the last dot in
>>> the authority component.
>> 
>> That's a fair point. Would referencing RFC 1034 in that section
>> address your concern? I would rather not have to define subdomain
>> ourselves but rather reuse what already exists!
> 
> Sounds good to me, although I think I would also rephrase somewhat the
> algorithm, à la:
> * the URI's scheme component is the same as scheme; and
> * if subdomains is false or if the URI's host component is not a domain
> name (as defined in RFC1034), the URI's host component is the same as
> host; or
> * if subdomains is true, the URI's host component is either the same as
> host, or is a subdomain of host (as defined in RFC1034); and

Good suggestion, the latest ED reflects the above change plus another reference 
where subdomains are defined.

Please let us know if that works for you!

-- 
Robin Berjon - http://berjon.com/

Re: [widgets] Request for Comments: LCWD of Widget Access Request Policy spec; deadline 13-Jan-2010

[Robin Berjon]

Hi Marcos,

On Dec 21, 2009, at 16:06 , Marcos Caceres wrote:
>> An access request is a request made by an author to the user agent for
>> the ability to retrieve one or more network resources. The network
>> resources and author requests to access are identified using access
>> elements in the widget's configuration document.
> 
> I gots me confused by the second sentence, maybe change to:
> 
> "Requests by an author to access network resources can be identified
> by the presence of access elements in the widget's configuration document."

Sounds just as confused to me. How about:

"Access element in the widget's configuration document express the author's 
requests to access network resources."

?

>> 3. Conformance
>> This specification defines conformance criteria that apply to a single
>> product: user agents that implement the interfaces that it contains.
> 
> It's confusing to talk about "interfaces" here, though I understand
> you are talking about interfaces in general terms. I would prefer if
> the spec just said:
> 
> "This specification defines conformance criteria that apply to a single
> product: user agents."
> 
> And a "user agent" be defined as "a software application that
> implements this specification and the [WIDGETS] specification and it's
> dependencies."

Okay.

>> A user agent enforces an access request policy. In the default policy,
>> a user agent must deny access to network resources external to the
>> widget by default, whether this access is requested through APIs (e.g.
>> XMLHttpRequest) or through markup (e.g. iframe, script, img).
> 
> i think you need to make it really clear that you've just defined the
> "default policy" for a WUA. Please make it a sub-section or something.

A subsection seems overkill for a single sentence. I'll split it into its own 
paragraph and make sure it's a dfn.

>> The exact rules defining which execution scope applies to network
>> resources loaded into a document running in the widget execution scope
>> depend on the language that is being used inside the the widget.
> 
> Typo: "the the"

Okay.


>> 5. The access Element
>> Context in which this element may be used:
> 
> P&C uses "Context in which this element is used:". It would be nice if
> this one said the same thing :)

Okay!

>> 5.1 Attributes
>> 
>> origin
>> An IRI attribute that defines the specifics of the access request that
>> is requested.
> 
> "that is requested" seems tautological... and makes the sentence read
> funny (and not "ha ha" funny.)

I'll make it "that is made".

> "Additionally, an author can use the special value of U+002A ASTERISK (*):"

Okay.

>> This special value provides a means for an author to
>> request from the user agent unrestricted access to network resources.
> 
> Break here.

It's HAMMERTIME!

>> Only the scheme and authority components can be present in the IRI
>> that this attribute contains ([URI], [RFC3987]).
> 
> I'm really sorry, I'm having a hard time parsing the above sentence.
> At first, I thought it was related to the sentence about "*". Can you
> change the order of these sentences above. Also, the "*" value is
> pretty important, maybe it deserves it's own sub-section even if it
> just contains one short paragraph. i'm sure people will come back
> asking for clarification once we go to CR as to how it's supposed to
> work.

I'll split and clarify.

>> subdomains
>> A boolean attribute that indicates whether or not the host component
>> part of the access request applies to subdomains of domain in the
>> origin attribute.
> 
> It should be clear that "subdomains" and "domain" here refers to
> components of RFC-such-and-such, right?

Yup, adding a reference to RFC 1034.

>> The default value when this attribute is absent is
>> false, meaning that access to subdomains is not requested.
> 
> what does it means when I have:
> 
> http://foo.bar.woo.com"; subdomains="true"/>
> 
> Everything before "woo.com" is allowed, right? Maybe could be clear in
> the spec for people like me :)

Err no, everything below foo.bar.woo.com. Maybe after reading RFC 1034 it'll be 
clearer?

"""
A domain is a subdomain of another domain if it
is contained within that domain.  This relationship can be tested by
seeing if the subdomain's name ends with the containing domain's name.
For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
"""

>> 5.2 Usage example
>> 
>> This example contains multiple uses of the access element (not
>> contained in the same configuration as the last one would make the
>> others useless).
> 
> The above sentence doesn't tell me anything (that I can understand)
> about the example. It be nice if it told me what I was looking at a
> bit more. Maybe you need to break this up into multiple examples,
> showing when it would be appropriate to use "*".

I'll clarify it somewhat (though it seems perfectly clear to me — it's several 
examples of the element!).

>> They presume that http://www.w3.org/ns/widgets is the
>> default namespace d

RE: Event handlers - Pointer Devices

[SULLIVAN, BRYAN L (ATTCINW)]

OK, I agree, let's see a draft horse first, then later we can decide if it was 
worth dressing it up for the cart.

On the main (or more useful) point perhaps, I think the distinction between a 
device's internal features, its peripherals as attached features, and more 
abstracted (even remote) resources is still very blurry between Webapps and 
DAP. For example, DAP is considering whether to represent device API's (called 
"device" here only because in some instances the resource provider might be 
local to the device) using an abstracted RESTful model ("Powerbox") that I have 
asserted fits better in the Web API work in Webapps, because it's more aligned 
with the RESTful model of remote resource access over HTTP. And here we have 
consideration of screen input and mouse events, which are resources of the host 
device, at least when attached to it.

I'd like to see some clearer distinction between the charters on these points. 

Thanks, 
Bryan Sullivan | AT&T

-Original Message-
From: Doug Schepers [mailto:schep...@w3.org] 
Sent: Thursday, March 04, 2010 7:08 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: Charles Pritchard; public-webapps@w3.org
Subject: Re: Event handlers - Pointer Devices

Hi, Bryan-

SULLIVAN, BRYAN L (ATTCINW) wrote (on 3/4/10 9:15 AM):
> This might be better discussed by the DAP group, as it's clearly a
> "device API" topic.

By that definition, a mouse would be a device. :)  This work belongs in 
the WebApps WG, and it is explicitly mentioned in our charter, to be 
taken up during our next charter period.

DAP is not focused on user-input devices, more on things like cameras, 
calendars, etc. available on the local device.


> Also it would be interesting to hear from Apple and Wacom (without
> unnecessary details at this point), what areas of touch interface
> capabilities would be problematic for W3C to create API's for, from an
> IPR perspective (i.e. that would probably result in exclusions)... this
> concern is driven e.g. by the current touch-related issue between Apple
> and HTC.

This is putting the cart before the horse.  It's not appropriate to 
discuss IPR at this point, since we don't even have a draft spec (by 
design).  Once we have a draft of the spec, participants who have IPR 
can have their legal team look at it and chime in at that point (though 
this may take place in Member space, since they may wish to do so under 
the legal framework of W3C Member confidentiality).

I am concerned that it may not be fruitful, and may be 
counterproductive, for us to start speculating on this list about IPR. 
Let's keep the discussion on technical matters, please.

However, use cases and requirements would be appropriate to discuss, and 
this should help frame a successful outcome for this spec.

[1] http://www.w3.org/2009/05/DeviceAPICharter

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: [WARP] comment on subdomains

[Dominique Hazael-Massieux]

Le jeudi 04 mars 2010 à 15:51 +0100, Robin Berjon a écrit :
> On Dec 10, 2009, at 16:51 , Dominique Hazael-Massieux wrote:
> > A quick comment after re-reading WARP at the invitation of Robin to DAP
> > [1]: I don’t think the notion of subdomain is well-defined; is w3.org a
> > subdomain of .org? is co a subdomain of co.uk? I assume they are in the
> > sense of the spec, but if that’s so, it doesn’t match the “street”
> > meaning of the word “subdomain”; this matters in particular in section 7
> > (rules for granting access), since this has an impact on how a user
> > agent decides to grant access to a network resource. Given that IP
> > addresses are allowed, the algorithm to determine if something is a
> > subdomain of another domain is as simple as looking to the last dot in
> > the authority component.
> 
> That's a fair point. Would referencing RFC 1034 in that section
> address your concern? I would rather not have to define subdomain
> ourselves but rather reuse what already exists!

Sounds good to me, although I think I would also rephrase somewhat the
algorithm, à la:
* the URI's scheme component is the same as scheme; and
* if subdomains is false or if the URI's host component is not a domain
name (as defined in RFC1034), the URI's host component is the same as
host; or
* if subdomains is true, the URI's host component is either the same as
host, or is a subdomain of host (as defined in RFC1034); and
* ...

Dom

Re: Event handlers - Pointer Devices

[Doug Schepers]

Hi, Bryan-

SULLIVAN, BRYAN L (ATTCINW) wrote (on 3/4/10 9:15 AM):

This might be better discussed by the DAP group, as it's clearly a
"device API" topic.


By that definition, a mouse would be a device. :)  This work belongs in 
the WebApps WG, and it is explicitly mentioned in our charter, to be 
taken up during our next charter period.


DAP is not focused on user-input devices, more on things like cameras, 
calendars, etc. available on the local device.




Also it would be interesting to hear from Apple and Wacom (without
unnecessary details at this point), what areas of touch interface
capabilities would be problematic for W3C to create API's for, from an
IPR perspective (i.e. that would probably result in exclusions)... this
concern is driven e.g. by the current touch-related issue between Apple
and HTC.


This is putting the cart before the horse.  It's not appropriate to 
discuss IPR at this point, since we don't even have a draft spec (by 
design).  Once we have a draft of the spec, participants who have IPR 
can have their legal team look at it and chime in at that point (though 
this may take place in Member space, since they may wish to do so under 
the legal framework of W3C Member confidentiality).


I am concerned that it may not be fruitful, and may be 
counterproductive, for us to start speculating on this list about IPR. 
Let's keep the discussion on technical matters, please.


However, use cases and requirements would be appropriate to discuss, and 
this should help frame a successful outcome for this spec.


[1] http://www.w3.org/2009/05/DeviceAPICharter

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[widgets] Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17

[Arthur Barstow]

This is the start of a 2-week pre-LCWD call for comments re the View  
Modes Media Feature spec:


 http://dev.w3.org/2006/waf/widgets-vmmf/Overview.html

If you have any comments, please send them to public-webapps@w3.org  
by March 17.


Note the Process Document states the following regarding the  
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant  
technical requirements (e.g., of the charter or requirements  
document) in the Working Draft;


* the Working Group believes that it has satisfied significant  
dependencies with other groups;


* other groups SHOULD review the document to confirm that these  
dependencies have been satisfied. In general, a Last Call  
announcement is also a signal that the Working Group is planning to  
advance the technical report to later maturity levels.

]]

Additionally, a LCWD should be considered feature-complete with all  
issues resolved.


We will explicitly ask the CSS WG (via the www-style mail list) for  
comments. If there are other groups that should be asked for  
comments, please forward this email to them or identify the group(s).


-Art Barstow


Begin forwarded message:


From: ext Robin Berjon 
Date: March 4, 2010 8:13:17 AM EST
To: public-webapps WG 
Subject: VMMF — new version
Archived-At: 


Hi all,

I just produced an update of VMMF to make it ready for publication:  
http://dev.w3.org/2006/waf/widgets-vmmf/.


Essentially I changed it so that it corresponds to CSS Media  
Queries. That, plus it being a UI oriented specification, means  
that there's only one normative assertion and it's a SHOULD.


Comments welcome, I think that this baby can ship.

--
Robin Berjon - http://berjon.com/

Re: [WARP] comment on subdomains

[Robin Berjon]

Hi Dom,

On Dec 10, 2009, at 16:51 , Dominique Hazael-Massieux wrote:
> A quick comment after re-reading WARP at the invitation of Robin to DAP
> [1]: I don’t think the notion of subdomain is well-defined; is w3.org a
> subdomain of .org? is co a subdomain of co.uk? I assume they are in the
> sense of the spec, but if that’s so, it doesn’t match the “street”
> meaning of the word “subdomain”; this matters in particular in section 7
> (rules for granting access), since this has an impact on how a user
> agent decides to grant access to a network resource. Given that IP
> addresses are allowed, the algorithm to determine if something is a
> subdomain of another domain is as simple as looking to the last dot in
> the authority component.

That's a fair point. Would referencing RFC 1034 in that section address your 
concern? I would rather not have to define subdomain ourselves but rather reuse 
what already exists!

> (kudos on the spec otherwise; I find it to be very crisp)

Thanks!

-- 
Robin Berjon - http://berjon.com/

[widgets] Draft Minutes for 4 March 2010 voice conference

[Arthur Barstow]

The draft minutes from the March 4 Widgets voice conference are  
available at the following and copied below:


 http://www.w3.org/2010/03/04-wam-minutes.html

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before March 18 (the next  
Widgets voice conference); otherwise these minutes will be considered  
Approved.


-Regards, Art Barstow

   [1]W3C

  [1] http://www.w3.org/

   - DRAFT -

   Widgets Voice Conference

04 Mar 2010

   [2]Agenda

  [2] http://lists.w3.org/Archives/Public/public-webapps/ 
2010JanMar/0741.html


   See also: [3]IRC log

  [3] http://www.w3.org/2010/03/04-wam-irc

Attendees

   Present
  Art, Bryan, Marcos, Robin, Arve, StevenP

   Regrets
  Marcin

   Chair
  Art

   Scribe
  Art

Contents

 * [4]Topics
 1. [5]Review and tweak agenda
 2. [6]Announcements?
 3. [7]P&C spec:  element and dir attribute
 4. [8]WARP spec
 5. [9]URI scheme spec
 6. [10]View Modes Media Feature spec
 7. [11]AOB
 * [12]Summary of Action Items
 _

joining in a split second!

ScribeNick: ArtB

Scribe: Art

   Date: 4 March 2010

Review and tweak agenda

   AB: the draft agenda was posted on March 3 (
   [13]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/07
   41.html ). Will add View Modes Media Features to the agenda since
   Robin posted an update today (
   [14]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/07
   45.html ). Any other change requests?

 [13] http://lists.w3.org/Archives/Public/public-webapps/ 
2010JanMar/0741.html
 [14] http://lists.w3.org/Archives/Public/public-webapps/ 
2010JanMar/0745.html


Announcements?

   AB: I have one: No call next week on March 11; next call will be
   March 18. Any other short announcements?

P&C spec:  element and dir attribute

   AB: earlier this week Marcos submitted a proposal on how to address
   the  element and dir attribute (
   [15]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/07
   15.html ).

 [15] http://lists.w3.org/Archives/Public/public-webapps/ 
2010JanMar/0715.html


   MC: I'm waiting to see what the I18N WG says
   ... I added  and dir attr to the spec
   ... but I have not spec'ed he behavior
   ... we want to defer the proc model to a sepearate spec

   AB: is that proving to be problematic?

   MC: it's a bit complicated
   ... the bidi stuff that is
   ... if dir attr is set globally, need to set limits
   ... some stuff such as IRI interaction isn't clear
   ... for example  has a short name
   ... could have name in English and short name in Hebrew

   AB: are you having a diaglog with I18N group?

   MC: they were supposed to discuss it yesterday
   ... haven't seen their minutes yet
   ... Scott and Addison have been discussing it
   ... not clear how attrs are affected by direction

   AB: what's the prior art?

   MC: HTML5
   ... but I think it is underspecified

   AB: other formats?

   MC: SVG is likely
   ... so we could check it

   AB: I would expect a lot of languages

   RB: SMIL, XForms, etc.

... DocBook, TEI

   AB: can we minimize the changes to P&C and defer all processing to
   the separate spec?

   MC: yes, that's the intent but not clear if we can get that
   ... when an impl gets back a dir string, it's got additional
   semantics in it

   SP: can't we just use CSS for this?
   ... CSS has a rule that matches bidi algorithm

   MC: there is no style associated with config.xml
   ... that is also discouraged in some places e.g. HTML5
   ... the behavior we are looking for is indeed defined in CSS

   SP: can't we just say the text included behaves the same rules as
   CSS

   MC: yes, that is part of the solution
   ... but there are additional issues too

   AB: let's pause to see if the I18N WG has posted their minutes from
   yesterday's discussion

   MC: yes, sure

   AB: I just checked their archive and see no postings on March 3 or 4

[16]http://www.w3.org/2010/03/03-pf-minutes.html

 [16] http://www.w3.org/2010/03/03-pf-minutes.html

is that it?

   AB: OK, so what is the plan of action

   MC: need to continue the investigation
   ... in my last email to them I asked them questions
   ... we need to get their answers

ACTION: barstow followup with Richard and Addison re the
and dir attribute discussions [recorded in
   [17]http://www.w3.org/2010/03/04-wam-minutes.html#action01]

Created ACTION-506 - Followup with Richard and Addison re
   the  and dir attribute discussions [on Arthur Barstow - due
   2010-03-11].

   AB: the draft agenda includes a discussion on the Widget BiDi spec
   ... I presume there is no need to discuss that now

   MC: yes, that's correct; we need to get feedback from I18N WG
   ... this is a new and compl

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Thu, Mar 4, 2010 at 2:37 PM, Jeremy Orlow  wrote:

> On Wed, Mar 3, 2010 at 8:48 PM, Kris Zyp  wrote:
>
>>  -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>
>> On 3/3/2010 4:01 AM, Jeremy Orlow wrote:
>> > On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp > >  > wrote:
>> > [snip]
>>
>> >
>> > > The promises would only have a
>> > "then" method which would take in an
>> >
>> > > onsuccess and onerror callback.  Both are optional.  The
>> > onsuccess
>> >
>> > > function should take in a single parameter which matches the
>> > return
>> >
>> > > value of the synchronous counterpart.  The onerror function
>> > should
>> >
>> > > take in an IDBDatabaseError.  If the callbacks are null,
>> > undefined,
>> >
>> > > or omitted, they're ignored.  If they're anything else, we should
>> >
>> > > probably either raise an exception immediately or ignore them.
>> >
>> > Yes.
>> >
>> >
>> > Any thoughts on whether we'd raise or ignore improper inputs?  I'm
>> > leaning towards raise since it would be deterministic and silently
>> > ignoring seems like a headache from a developer standpoint.
>>
>> Throwing an error on improper inputs is fine with me.
>>
>> >
>> >
>> > > If there's an error, all onerror
>> > callbacks would be called with the
>> >
>> > > IDBDatabaseError.
>> >
>> > Yes.
>> >
>> >
>> > > Exceptions within callbacks
>> > would be ignored.
>> >
>> > With CommonJS promises, the promise returned by the then() call goes
>> > into an error state if a callback throws an exception. For example,
>> >
>> > someAsyncOperation.then(successHandler, function(){ throw new
>> > Error("test") })
>> > .then(null, function(error){ console.log(error); });
>> >
>> > Would log the thrown error, effectively giving you a way of catching
>> > the error.
>> >
>> > Are you suggesting this as a simplification so that IndexedDB impls
>> > doesn't have to worry about recursive creation of promises? If so, I
>> > suppose that seems like a reasonable simplification to me.
>> > Although if
>> > promises are something that could be potentially reused in other
>> > specs, it would be nice to have a quality solution, and I don't
>> > think
>> > this is a big implementation burden, I've implemented the recursive
>> > capabilities in dozen or two lines of JS code. But if burden is too
>> > onerous, I am fine with the simplification.
>> >
>> >
>> > When you say "recursive capabilities" are you just talking about how
>> > to handle exceptions, or something more?
>> >
>> > In terms of exceptions: I don't think it's an
>> > enormous implementational burden and thus I think it's fine to
>> > ignore that part of the equation.  So the question mainly comes down
>> > to whether the added complexity is worth it.  Can you think of any
>> > real-world examples of when this capability is useful in promises?
>> >  If so, that'd definitely help us understand the pro's and con's.
>>
>> Maybe I misunderstanding your suggestion. By "recursive capability" I
>> meant having then() return a promise (that is fulfilled with the
>> result of executing the callback), and I thought you were suggesting
>> that instead, then() would not return a promise. If then() returns a
>> promise, I think the returned promise should clearly go into an error
>> state if the callback throws an error. The goal of promises is to
>> asynchronously model computations, and if a computation throws, it
>> should result in the associated promise entering error state. The
>> promise returned by then() exists to represent the result of the
>> execution of the callback, and so it should resolve to the value
>> returned by the callback or an error if the callback throws. Silenty
>> swallowing errors seems highly undesirable.
>>
>> Now if we are simplifying then() to not return a promise at all, than
>> I would think callbacks would just behave like any other event
>> listener in regards to uncaught errors.
>>
>
> You are quite right!  I misunderstood how this part of promises worked.
>
> Is there excitement about speccing promises in general?  If not, it seems a
> little odd to spec such a powerful mechanism into just IndexedDBand it
> might be best to spec the simplified version of .then(): .then() will return
> undefined, onsuccess/onerror's return values will be swallowed, and any
> thrown exceptions will be thrown.
>

Erthrown exceptions will be _swallowed_ (not thrown).


> This should make it easy to make IndexedDB support full blown promises
> if/whenever they're specced.  (It's not clear to me whether UA support for
> them would offer enough advantages to warrant it.)
>
> It sounds like you're OK with such an approach, Kris?
>
> What do others think?
>
> J
>
>
>>  >
>> > > In terms of speccing, I'm not sure if we can get away with
>> > speccing
>> >
>> > > one promise interface or whether we'd 

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Wed, Mar 3, 2010 at 8:48 PM, Kris Zyp  wrote:

>  -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 3/3/2010 4:01 AM, Jeremy Orlow wrote:
> > On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp  >  > wrote:
> > [snip]
>
> >
> > > The promises would only have a
> > "then" method which would take in an
> >
> > > onsuccess and onerror callback.  Both are optional.  The
> > onsuccess
> >
> > > function should take in a single parameter which matches the
> > return
> >
> > > value of the synchronous counterpart.  The onerror function
> > should
> >
> > > take in an IDBDatabaseError.  If the callbacks are null,
> > undefined,
> >
> > > or omitted, they're ignored.  If they're anything else, we should
> >
> > > probably either raise an exception immediately or ignore them.
> >
> > Yes.
> >
> >
> > Any thoughts on whether we'd raise or ignore improper inputs?  I'm
> > leaning towards raise since it would be deterministic and silently
> > ignoring seems like a headache from a developer standpoint.
>
> Throwing an error on improper inputs is fine with me.
>
> >
> >
> > > If there's an error, all onerror
> > callbacks would be called with the
> >
> > > IDBDatabaseError.
> >
> > Yes.
> >
> >
> > > Exceptions within callbacks
> > would be ignored.
> >
> > With CommonJS promises, the promise returned by the then() call goes
> > into an error state if a callback throws an exception. For example,
> >
> > someAsyncOperation.then(successHandler, function(){ throw new
> > Error("test") })
> > .then(null, function(error){ console.log(error); });
> >
> > Would log the thrown error, effectively giving you a way of catching
> > the error.
> >
> > Are you suggesting this as a simplification so that IndexedDB impls
> > doesn't have to worry about recursive creation of promises? If so, I
> > suppose that seems like a reasonable simplification to me.
> > Although if
> > promises are something that could be potentially reused in other
> > specs, it would be nice to have a quality solution, and I don't
> > think
> > this is a big implementation burden, I've implemented the recursive
> > capabilities in dozen or two lines of JS code. But if burden is too
> > onerous, I am fine with the simplification.
> >
> >
> > When you say "recursive capabilities" are you just talking about how
> > to handle exceptions, or something more?
> >
> > In terms of exceptions: I don't think it's an
> > enormous implementational burden and thus I think it's fine to
> > ignore that part of the equation.  So the question mainly comes down
> > to whether the added complexity is worth it.  Can you think of any
> > real-world examples of when this capability is useful in promises?
> >  If so, that'd definitely help us understand the pro's and con's.
>
> Maybe I misunderstanding your suggestion. By "recursive capability" I
> meant having then() return a promise (that is fulfilled with the
> result of executing the callback), and I thought you were suggesting
> that instead, then() would not return a promise. If then() returns a
> promise, I think the returned promise should clearly go into an error
> state if the callback throws an error. The goal of promises is to
> asynchronously model computations, and if a computation throws, it
> should result in the associated promise entering error state. The
> promise returned by then() exists to represent the result of the
> execution of the callback, and so it should resolve to the value
> returned by the callback or an error if the callback throws. Silenty
> swallowing errors seems highly undesirable.
>
> Now if we are simplifying then() to not return a promise at all, than
> I would think callbacks would just behave like any other event
> listener in regards to uncaught errors.
>

You are quite right!  I misunderstood how this part of promises worked.

Is there excitement about speccing promises in general?  If not, it seems a
little odd to spec such a powerful mechanism into just IndexedDBand it
might be best to spec the simplified version of .then(): .then() will return
undefined, onsuccess/onerror's return values will be swallowed, and any
thrown exceptions will be thrown.

This should make it easy to make IndexedDB support full blown promises
if/whenever they're specced.  (It's not clear to me whether UA support for
them would offer enough advantages to warrant it.)

It sounds like you're OK with such an approach, Kris?

What do others think?

J


>  >
> > > In terms of speccing, I'm not sure if we can get away with
> > speccing
> >
> > > one promise interface or whether we'd need to create one for each
> >
> > > type of promise.
> >
> > Certainly the intent of promises is that there is exists only one
> > generic promise interface that can be reused everywhere, at
> > least from
> > the JS perspective, not 

RE: Event handlers - Pointer Devices

[SULLIVAN, BRYAN L (ATTCINW)]

This might be better discussed by the DAP group, as it's clearly a
"device API" topic.

Also it would be interesting to hear from Apple and Wacom (without
unnecessary details at this point), what areas of touch interface
capabilities would be problematic for W3C to create API's for, from an
IPR perspective (i.e. that would probably result in exclusions)... this
concern is driven e.g. by the current touch-related issue between Apple
and HTC.

Thanks, 
Bryan Sullivan | AT&T

-Original Message-
From: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Charles Pritchard
Sent: Tuesday, March 02, 2010 5:18 PM
To: public-webapps@w3.org
Subject: Event handlers - Pointer Devices

This is a re-post from the WHATWG mailing list.

They've suggested I take the discussion to this list, as
pointer events have not yet been formalized.



I'd like to know if there's room or any work has been done to set aside
a
standard for an extended set of pointer-device events.

With touch screens and touch sensitivity becoming quite main-stream,
I'd like to see this popular functionality supported by the HTML 5 
standard.

We see, in the iPhone, an ontouchstart and ongesturestart, and company.
Gesture is a nice way of saying multiple inputs, and it works well.

While many people would like to wrap the ontouch events into onmouse
events -- they do have some different semantics. And, I believe
that ontouch would be a good place to add in pressure sensitivity
indexes.

So, I thought I'd solicit feedback here.

I'd like a common API to support touch screens
and pressure/angle sensitive touch devices.

I believe that both Apple and Wacom have thrown their hats into the 
ring, and we can easily
integrate their achievements.


-Charles

VMMF — new version

[Robin Berjon]

Hi all,

I just produced an update of VMMF to make it ready for publication: 
http://dev.w3.org/2006/waf/widgets-vmmf/.

Essentially I changed it so that it corresponds to CSS Media Queries. That, 
plus it being a UI oriented specification, means that there's only one 
normative assertion and it's a SHOULD.

Comments welcome, I think that this baby can ship.

-- 
Robin Berjon - http://berjon.com/