Re: IndexedDB: calling IDBTransaction.objectStore() or IDBObjectStore.index() after transaction is finished?

2011-12-15 Thread Jonas Sicking 
On Thu, Dec 15, 2011 at 12:54 PM, Joshua Bell  wrote:
> Is there any particular reason why IDBTransaction.objectStore() and
> IDBObjectStore.index() should be usable (i.e. return values vs. raise
> exceptions) after the containing transaction has finished?
>
> Changing the spec so that calling these methods after the containing
> transaction has finished raises InvalidStateError (or
> TransactionInactiveError) could simplify implementations.

That would be ok with me.

Please file a bug though.

/ Jonas

Re: Barewords in on* attributes, redux (also, find() and company)

2011-12-15 Thread Boris Zbarsky 

On 12/14/11 4:52 PM, Boris Zbarsky wrote:

Ok. It's just a simple spider that starts with the list at
http://code.google.com/p/httparchive/source/browse/trunk/lists/All.txt
and for each of those urls loads the url itself and then follows all
same-host links from that page. So loads the front page of the site and
all the same-host one-level-deep pages.


One more note.  The data I have so far is from just looking at 1000 
sites, not all 25000-some.  John's still working on that last, now that 
he has this set up on more beefy hardware.


-Boris

Re: [Pointer Lock] Few comments

2011-12-15 Thread Olli Pettay 

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=711276
and https://bugs.webkit.org/show_bug.cgi?id=74660


On 12/16/2011 01:49 AM, Olli Pettay wrote:

On 12/16/2011 01:04 AM, Darin Fisher wrote:



On Thu, Dec 15, 2011 at 1:39 PM, Olli Pettay mailto:olli.pet...@helsinki.fi>> wrote:

On 12/15/2011 11:27 PM, Vincent Scheib wrote:



On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay
mailto:olli.pet...@helsinki.fi>
>> wrote:

Hi all,

few comments about the API

(1)
currently
http://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.html


>
uses VoidCallback which isn't defined anywhere.

I guess there should be something like

void lock (in Element target,
optional in LockSuccessCallback successCallback,
optional in LockErrorCallback failureCallback);


[Callback,NoInterfaceObject]
interface LockSuccessCallback {
void pointerLockSuccess();
};

[Callback,NoInterfaceObject]
interface LockErrorCallback {
void pointerLockFailure();
};

Or if the new proposed callback syntax is used:
callback LockSuccessCallback = void pointerLockSuccess();
callback LockErrorCallback = void pointerLockFailure();


I used the concept of VoidCallback from other implemented specs. Are
there any issues with it other than that the spec should define
VoidCallback? e.g.
http://www.w3.org/TR/file-__system-api/#the-voidcallback-__interface

http://www.w3.org/TR/2009/WD-__DataCache-20091029/#__VoidCallback



well, in those specs VoidCallback is FunctionOnly= which it probably
shouldn't be.
But there is ongoing discussion about removing FunctionOnly= from
WebIDL





(2)
"If another element is locked a user agent must transfer the mouse
lock to the new target and call the pointerlocklost callback
for the
previous target."
There is no such thing as 'pointerlocklost callback'


Spec typo, it should read "pointerlocklost event".


dispatch pointerlocklost event...





(3)
"Mouse lock must succeed only if the window is in focus and the
user-agent is the active application of the operating system"
What window? window object as in web page? Or OS level window?
What if lock is called in some iframe?


The intent is the user-agent window and tab (if tabbed UA).
Other than
UA security considerations, I propose there be no difference between
lock calls from a top level document or an iframe. Suggestions
welcome
for a way to make this more clear than rewriting to be, "... succeed
only if the user-agent window (and tab, if a tabbed browser) is
in focus
..."


I'm just worried about iframes being able to lock mouse.
But perhaps that should be allowed only if the iframe is in
the same domain as the top level document.


The fullscreen API requires that the IFRAME tag have an
"allowfullscreen" attribute:
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#security-and-privacy-considerations



The spec is quite vague, but yes, something similar could work.

I wonder if we're going to have more this kinds of features. If so,
perhaps the attribute should be changed.
Something like
allow="fullscreen pointerlock"





Perhaps a similar approach would work for pointer lock?

-Darin





(4)
"If the target is removed from the DOM tree after mouse lock is
entered then mouse lock will be lost."
Should 'pointerlocklost' event be dispatched?


I'm not yet certain about the implementation practicalities, and
need to
research more, but is seems we have these options:
a- don't send the event

A bit strange



b- send to the element after it has been detached

I would assume this. At least it would be consistent.



c- send to the nearest ancestor of the element that remains in
the tree

Or perhaps send to the document. Should pointerlocklost always be
dispatched to the document? If really needed, the event could have
property .unlockedElement or some such.



d- send to the element before it is detached

this is not possible. Well, possible, but would bring in all the
problems there are with mutation events


-Olli

Re: [Pointer Lock] Few comments

2011-12-15 Thread Olli Pettay 

On 12/16/2011 01:04 AM, Darin Fisher wrote:



On Thu, Dec 15, 2011 at 1:39 PM, Olli Pettay mailto:olli.pet...@helsinki.fi>> wrote:

On 12/15/2011 11:27 PM, Vincent Scheib wrote:



On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay
mailto:olli.pet...@helsinki.fi>
>> wrote:

Hi all,

few comments about the API

(1)
currently
http://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.html


>
uses VoidCallback which isn't defined anywhere.

I guess there should be something like

void lock (in Element target,
   optional in LockSuccessCallback successCallback,
   optional in LockErrorCallback failureCallback);


[Callback,NoInterfaceObject]
interface LockSuccessCallback {
  void pointerLockSuccess();
};

[Callback,NoInterfaceObject]
interface LockErrorCallback {
  void pointerLockFailure();
};

Or if the new proposed callback syntax is used:
callback LockSuccessCallback = void pointerLockSuccess();
callback LockErrorCallback = void pointerLockFailure();


I used the concept of VoidCallback from other implemented specs. Are
there any issues with it other than that the spec should define
VoidCallback? e.g.
http://www.w3.org/TR/file-__system-api/#the-voidcallback-__interface

http://www.w3.org/TR/2009/WD-__DataCache-20091029/#__VoidCallback 



well, in those specs VoidCallback is FunctionOnly= which it probably
shouldn't be.
But there is ongoing discussion about removing FunctionOnly= from
WebIDL





(2)
"If another element is locked a user agent must transfer the mouse
lock to the new target and call the pointerlocklost callback
for the
previous target."
There is no such thing as 'pointerlocklost callback'


Spec typo, it should read "pointerlocklost event".


dispatch pointerlocklost event...





(3)
"Mouse lock must succeed only if the window is in focus and the
user-agent is the active application of the operating system"
What window? window object as in web page? Or OS level window?
What if lock is called in some iframe?


The intent is the user-agent window and tab (if tabbed UA).
Other than
UA security considerations, I propose there be no difference between
lock calls from a top level document or an iframe. Suggestions
welcome
for a way to make this more clear than rewriting to be, "... succeed
only if the user-agent window (and tab, if a tabbed browser) is
in focus
..."


I'm just worried about iframes being able to lock mouse.
But perhaps that should be allowed only if the iframe is in
the same domain as the top level document.


The fullscreen API requires that the IFRAME tag have an
"allowfullscreen" attribute:
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#security-and-privacy-considerations


The spec is quite vague, but yes, something similar could work.

I wonder if we're going to have more this kinds of features. If so, 
perhaps the attribute should be changed.

Something like
allow="fullscreen pointerlock"





Perhaps a similar approach would work for pointer lock?

-Darin





(4)
"If the target is removed from the DOM tree after mouse lock is
entered then mouse lock will be lost."
Should 'pointerlocklost' event be dispatched?


I'm not yet certain about the implementation practicalities, and
need to
research more, but is seems we have these options:
a- don't send the event

A bit strange



b- send to the element after it has been detached

I would assume this. At least it would be consistent.



c- send to the nearest ancestor of the element that remains in
the tree

Or perhaps send to the document. Should pointerlocklost always be
dispatched to the document? If really needed, the event could have
property .unlockedElement or some such.



d- send to the element before it is detached

this is not possible. Well, possible, but would bring in all the
problems there are with mutation events


-Olli

[Bug 15223] New: Need to add an DOMError error attribute to the IDBTransaction interface

2011-12-15 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15223

   Summary: Need to add an DOMError error attribute to the
IDBTransaction interface
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: isra...@microsoft.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


The intent of this attribute is to surface fatal errors that are not
necessarily associated with an individual requests but happened during the
commit of the transaction.

More information about this bug can be found at:
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0059.html

Israel

-- 
Configure bugmail: https://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: [Pointer Lock] Few comments

2011-12-15 Thread Darin Fisher 
On Thu, Dec 15, 2011 at 1:39 PM, Olli Pettay wrote:

> On 12/15/2011 11:27 PM, Vincent Scheib wrote:
>
>>
>>
>> On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay > > wrote:
>>
>>Hi all,
>>
>>few comments about the API
>>
>>(1)
>>currently
>>http://dvcs.w3.org/hg/__**webevents/raw-file/default/__**
>> mouse-lock.html
>>
>>
>> 
>> >
>>uses VoidCallback which isn't defined anywhere.
>>
>>I guess there should be something like
>>
>>void lock (in Element target,
>>   optional in LockSuccessCallback successCallback,
>>   optional in LockErrorCallback failureCallback);
>>
>>
>>[Callback,NoInterfaceObject]
>>interface LockSuccessCallback {
>>  void pointerLockSuccess();
>>};
>>
>>[Callback,NoInterfaceObject]
>>interface LockErrorCallback {
>>  void pointerLockFailure();
>>};
>>
>>Or if the new proposed callback syntax is used:
>>callback LockSuccessCallback = void pointerLockSuccess();
>>callback LockErrorCallback = void pointerLockFailure();
>>
>>
>> I used the concept of VoidCallback from other implemented specs. Are
>> there any issues with it other than that the spec should define
>> VoidCallback? e.g.
>> http://www.w3.org/TR/file-**system-api/#the-voidcallback-**interface
>> http://www.w3.org/TR/2009/WD-**DataCache-20091029/#**VoidCallback
>>
>
> well, in those specs VoidCallback is FunctionOnly= which it probably
> shouldn't be.
> But there is ongoing discussion about removing FunctionOnly= from
> WebIDL
>
>
>
>
>>
>>(2)
>>"If another element is locked a user agent must transfer the mouse
>>lock to the new target and call the pointerlocklost callback for the
>>previous target."
>>There is no such thing as 'pointerlocklost callback'
>>
>>
>> Spec typo, it should read "pointerlocklost event".
>>
>
> dispatch pointerlocklost event...
>
>
>
>
>
>>(3)
>>"Mouse lock must succeed only if the window is in focus and the
>>user-agent is the active application of the operating system"
>>What window? window object as in web page? Or OS level window?
>>What if lock is called in some iframe?
>>
>>
>> The intent is the user-agent window and tab (if tabbed UA). Other than
>> UA security considerations, I propose there be no difference between
>> lock calls from a top level document or an iframe. Suggestions welcome
>> for a way to make this more clear than rewriting to be, "... succeed
>> only if the user-agent window (and tab, if a tabbed browser) is in focus
>> ..."
>>
>
> I'm just worried about iframes being able to lock mouse.
> But perhaps that should be allowed only if the iframe is in
> the same domain as the top level document.
>
>
The fullscreen API requires that the IFRAME tag have an "allowfullscreen"
attribute:
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#security-and-privacy-considerations

Perhaps a similar approach would work for pointer lock?

-Darin



>
>
>
>
>>(4)
>>"If the target is removed from the DOM tree after mouse lock is
>>entered then mouse lock will be lost."
>>Should 'pointerlocklost' event be dispatched?
>>
>>
>> I'm not yet certain about the implementation practicalities, and need to
>> research more, but is seems we have these options:
>> a- don't send the event
>>
> A bit strange
>
>
>
>  b- send to the element after it has been detached
>>
> I would assume this. At least it would be consistent.
>
>
>
>  c- send to the nearest ancestor of the element that remains in the tree
>>
> Or perhaps send to the document. Should pointerlocklost always be
> dispatched to the document? If really needed, the event could have
> property .unlockedElement or some such.
>
>
>
>  d- send to the element before it is detached
>>
> this is not possible. Well, possible, but would bring in all the
> problems there are with mutation events
>
>
> -Olli
>
>
>

IndexedDB: calling IDBTransaction.objectStore() or IDBObjectStore.index() after transaction is finished?

2011-12-15 Thread Joshua Bell 
Is there any particular reason why IDBTransaction.objectStore() and
IDBObjectStore.index() should be usable (i.e. return values vs. raise
exceptions) after the containing transaction has finished?

Changing the spec so that calling these methods after the containing
transaction has finished raises InvalidStateError (or
TransactionInactiveError) could simplify implementations.

Re: [Pointer Lock] Few comments

2011-12-15 Thread Olli Pettay 

On 12/15/2011 11:27 PM, Vincent Scheib wrote:



On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay mailto:olli.pet...@helsinki.fi>> wrote:

Hi all,

few comments about the API

(1)
currently
http://dvcs.w3.org/hg/__webevents/raw-file/default/__mouse-lock.html

uses VoidCallback which isn't defined anywhere.

I guess there should be something like

void lock (in Element target,
   optional in LockSuccessCallback successCallback,
   optional in LockErrorCallback failureCallback);


[Callback,NoInterfaceObject]
interface LockSuccessCallback {
  void pointerLockSuccess();
};

[Callback,NoInterfaceObject]
interface LockErrorCallback {
  void pointerLockFailure();
};

Or if the new proposed callback syntax is used:
callback LockSuccessCallback = void pointerLockSuccess();
callback LockErrorCallback = void pointerLockFailure();


I used the concept of VoidCallback from other implemented specs. Are
there any issues with it other than that the spec should define
VoidCallback? e.g.
http://www.w3.org/TR/file-system-api/#the-voidcallback-interface
http://www.w3.org/TR/2009/WD-DataCache-20091029/#VoidCallback


well, in those specs VoidCallback is FunctionOnly= which it probably 
shouldn't be.

But there is ongoing discussion about removing FunctionOnly= from
WebIDL





(2)
"If another element is locked a user agent must transfer the mouse
lock to the new target and call the pointerlocklost callback for the
previous target."
There is no such thing as 'pointerlocklost callback'


Spec typo, it should read "pointerlocklost event".


dispatch pointerlocklost event...





(3)
"Mouse lock must succeed only if the window is in focus and the
user-agent is the active application of the operating system"
What window? window object as in web page? Or OS level window?
What if lock is called in some iframe?


The intent is the user-agent window and tab (if tabbed UA). Other than
UA security considerations, I propose there be no difference between
lock calls from a top level document or an iframe. Suggestions welcome
for a way to make this more clear than rewriting to be, "... succeed
only if the user-agent window (and tab, if a tabbed browser) is in focus
..."


I'm just worried about iframes being able to lock mouse.
But perhaps that should be allowed only if the iframe is in
the same domain as the top level document.





(4)
"If the target is removed from the DOM tree after mouse lock is
entered then mouse lock will be lost."
Should 'pointerlocklost' event be dispatched?


I'm not yet certain about the implementation practicalities, and need to
research more, but is seems we have these options:
a- don't send the event

A bit strange



b- send to the element after it has been detached

I would assume this. At least it would be consistent.



c- send to the nearest ancestor of the element that remains in the tree
Or perhaps send to the document. Should pointerlocklost always be 
dispatched to the document? If really needed, the event could have

property .unlockedElement or some such.



d- send to the element before it is detached

this is not possible. Well, possible, but would bring in all the
problems there are with mutation events


-Olli

Re: [Pointer Lock] Few comments

2011-12-15 Thread Vincent Scheib 
On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay wrote:

> Hi all,
>
> few comments about the API
>
> (1)
> currently http://dvcs.w3.org/hg/**webevents/raw-file/default/**
> mouse-lock.htmluses
>  VoidCallback which isn't defined anywhere.
>
> I guess there should be something like
>
> void lock (in Element target,
>   optional in LockSuccessCallback successCallback,
>   optional in LockErrorCallback failureCallback);
>
>
> [Callback,NoInterfaceObject]
> interface LockSuccessCallback {
>  void pointerLockSuccess();
> };
>
> [Callback,NoInterfaceObject]
> interface LockErrorCallback {
>  void pointerLockFailure();
> };
>
> Or if the new proposed callback syntax is used:
> callback LockSuccessCallback = void pointerLockSuccess();
> callback LockErrorCallback = void pointerLockFailure();
>
>
I used the concept of VoidCallback from other implemented specs. Are there
any issues with it other than that the spec should define
VoidCallback? e.g.
http://www.w3.org/TR/file-system-api/#the-voidcallback-interface
http://www.w3.org/TR/2009/WD-DataCache-20091029/#VoidCallback



>
> (2)
> "If another element is locked a user agent must transfer the mouse lock to
> the new target and call the pointerlocklost callback for the previous
> target."
> There is no such thing as 'pointerlocklost callback'
>

Spec typo, it should read "pointerlocklost event".

(3)
> "Mouse lock must succeed only if the window is in focus and the user-agent
> is the active application of the operating system"
> What window? window object as in web page? Or OS level window?
> What if lock is called in some iframe?
>

The intent is the user-agent window and tab (if tabbed UA). Other than UA
security considerations, I propose there be no difference between lock
calls from a top level document or an iframe. Suggestions welcome for a way
to make this more clear than rewriting to be, "... succeed only if the
user-agent window (and tab, if a tabbed browser) is in focus ..."

(4)
> "If the target is removed from the DOM tree after mouse lock is entered
> then mouse lock will be lost."
> Should 'pointerlocklost' event be dispatched?


I'm not yet certain about the implementation practicalities, and need to
research more, but is seems we have these options:
a- don't send the event
b- send to the element after it has been detached
c- send to the nearest ancestor of the element that remains in the tree
d- send to the element before it is detached

Widget-DSig's choice of RSA-4096 Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-15 Thread Marcos Caceres 


On Thursday, December 15, 2011 at 4:51 PM, Brian LaMacchia wrote:

> 3) Widget-DSig's choice of RSA-4096 is particularly surprising given the 
> increased size of the signature & verification cost relative to ECDSA-SHA256. 
> That's not going to be efficient to validate, especially not for smartphones 
> and other low-power devices.

Strange… no implementer has reported any performance problems on phones? Phones 
have been the primary target platform for widgets and we worked pretty closely 
with around 10 OEMs or software vendors and this never came up. I've personally 
tested around 5 different runtimes (from WAC) and have never noticed any 
performance issue at boot (no real difference then starting a native app or 
anything I could perceive). Maybe I'm missing something?  

Kind regards,
Marcos  

--  
Marcos Caceres

Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-15 Thread Marcos Caceres 


On Thursday, December 15, 2011 at 4:51 PM, Brian LaMacchia wrote:

> Hello all,
>  
> Sorry for coming to this thread late (I'm on vacation) but I want to comment 
> on a number of points raised during this thread:
>  
> 1) Concerning the suggestion to move ECDSA out of XMLDSIG 1.1, that 
> suggestion is a non-starter for XMLDSIG. One of the main motivations for 
> XMLDSIG 1.1 is to update the spec to support Suite B cryptography, and that 
> means ECDSA support has to be there. Delaying ECC is not a viable option for 
> XMLDSIG.
The PAG has some good recommendations to help the situation (e.g., contributing 
prior art). If the patent can be showed to be invalid (or the party that 
disclosed is willing to work with the WG and the W3C around the patent), then 
the PAG can close quickly. Otherwise, I don't see much choice but to remove it 
ECC. There is no magic bullet.   
> 2) I do not understand the comments that Widget-DSig is independent of ECC. 
> As far as I can tell from reading the spec, while Widget-Dsig makes certain 
> recommendations about algorithms and key sizes legally Widget-DSig has to 
> work with any XMLDSIG 1.1 mandatory-to-implement option. That is, Widget-DSig 
> does not *profile* XMLDSIG 1.1 but simply says "use XMLDSIG 1.1". Since 
> ECDSA-SHA256 is a mandatory-to-implement signature algorithm in XMLDSIG 1.1, 
> every Widget-DSig implementation would have to support it (it would be 
> violating the XMLDSIG 1.1 spec otherwise).

In reality, no widget uses ECC, and no widget implementer implements ECC that I 
know of (call it a "willful" conformance violation - and no one will lose any 
sleep over not implementing a "mandatory-to-implement signature algorithm" that 
no one now dares to use). The spec can't force people to implement something 
patent encumbered for the sake of compliance, and recommendations can be 
ignored… as the are, after all, "recommendations" and not government standards 
that can be enforced by law (hence, there is no such thing as a 
"mandatory-to-implement signature algorithm": there is just goodwill to conform 
where it's not a (patented) problem to do so).  

Furthermore, specs should balance the needs of the market. Would it really be 
that bad to take our ECC and publish a companion spec with just ECC straight 
away? Should one aspect block the progression of the whole spec?   
  
> 3) Widget-DSig's choice of RSA-4096 is particularly surprising given the 
> increased size of the signature & verification cost relative to ECDSA-SHA256. 
> That's not going to be efficient to validate, especially not for smartphones 
> and other low-power devices.

Separate thread.   
>  
> 4) We (Microsoft, specifically Magnus and myself) are also distressed with 
> the lack of resolution to the ECC PAG and once again we strongly encourage 
> W3C staff to take a more active role in the PAG and lead it forward to its 
> logical conclusion.  
>  
> Widget-DSig is not the only spec out there with a dependency on the upcoming 
> XMLDSIG 1.1, but the fact that it is blocked too is all the more reason for 
> W3C to expedite conclusion of the PAG.  
>  


Amen! :)

RE: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-15 Thread Brian LaMacchia 
Hello all,

Sorry for coming to this thread late (I'm on vacation) but I want to comment on 
a number of points raised during this thread:

1) Concerning the suggestion to move ECDSA out of XMLDSIG 1.1, that suggestion 
is a non-starter for XMLDSIG.  One of the main motivations for XMLDSIG 1.1 is 
to update the spec to support Suite B cryptography, and that means ECDSA 
support has to be there.  Delaying ECC is not a viable option for XMLDSIG.

2) I do not understand the comments that Widget-DSig is independent of ECC.  As 
far as I can tell from reading the spec, while  Widget-Dsig makes certain 
recommendations about algorithms and key sizes legally Widget-DSig has to work 
with any XMLDSIG 1.1 mandatory-to-implement option.  That is, Widget-DSig does 
not *profile* XMLDSIG 1.1 but simply says "use XMLDSIG 1.1".  Since 
ECDSA-SHA256 is a mandatory-to-implement signature algorithm in XMLDSIG 1.1, 
every Widget-DSig implementation would have to support it (it would be 
violating the XMLDSIG 1.1 spec otherwise).

3) Widget-DSig's choice of RSA-4096 is particularly surprising given the 
increased size of the signature & verification cost relative to ECDSA-SHA256.  
That's not going to be efficient to validate, especially not for smartphones 
and other low-power devices.

4) We (Microsoft, specifically Magnus and myself) are also distressed with the 
lack of resolution to the ECC PAG and once again we strongly encourage W3C 
staff to take a more active role in the PAG and lead it forward to its logical 
conclusion. 

Widget-DSig is not the only spec out there with a dependency on the upcoming 
XMLDSIG 1.1, but the fact that it is blocked too is all the more reason for W3C 
to expedite conclusion of the PAG. 

--bal

-Original Message-
From: Thomas Roessler [mailto:t...@w3.org] 
Sent: Thursday, December 15, 2011 6:44 AM
To: Philippe Le Hegaret
Cc: Thomas Roessler; Arthur Barstow; Frederick Hirsch; Marcos Caceres; Doug 
Schepers; Rigo Wenning; public-webapps; public-xml...@w3.org
Subject: Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

Works for me, too.
--
Thomas Roessler, W3C(@roessler)







On 2011-12-13, at 22:14 +0100, Philippe Le Hegaret wrote:

> On Tue, 2011-12-13 at 13:14 -0500, Arthur Barstow wrote:
>> Hi All,
>> 
>> The Widgets DigSig spec [W-DigSig] has been sitting in PR for over 4 
>> months now, blocked on the Elliptic Curve PAG [ECC-PAG]. AFAICT, this 
>> PAG has just started its unspecified length Fishing Expedition 
>> seeking some unspecified level of funds to pay for some type of 
>> analysis that will take some unknown amount of time to complete ...
>> 
>> Given this, and not wanting to block on the ECC PAG any longer, what 
>> are the options to move widgets-digsig to REC ASAP?
>> 
>> Some options:
>> 
>> 1. Replace [XMLSig1.1] dependency with XMLSig 1.0. I presume this 
>> would require a new 3-week LC but the CR could be zero-length, 
>> presumably no re-testing would be required, and the only thing 
>> blocking PR->REC is the length of the new CfE that would be needed.
>> 
>> 2. Move the tainted algorithm(s) in XMLSig1.1 to XMLSig1.Next so
>> XMLSig1.1 is not affected by the PAG and XMLSig1.1 can then continue 
>> on the REC track.
>> 
>> 3. Others?
> 
> An other one was for the Director to decide to move the document 
> forward anyway because W-DigSig doesn't depend on ECC.
> 
> Thomas, any suggestion?
> 
> Philippe
> 
> 
>

Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-15 Thread Thomas Roessler 
Works for me, too.
--
Thomas Roessler, W3C(@roessler)







On 2011-12-13, at 22:14 +0100, Philippe Le Hegaret wrote:

> On Tue, 2011-12-13 at 13:14 -0500, Arthur Barstow wrote:
>> Hi All,
>> 
>> The Widgets DigSig spec [W-DigSig] has been sitting in PR for over 4 
>> months now, blocked on the Elliptic Curve PAG [ECC-PAG]. AFAICT, this 
>> PAG has just started its unspecified length Fishing Expedition seeking 
>> some unspecified level of funds to pay for some type of analysis that 
>> will take some unknown amount of time to complete ...
>> 
>> Given this, and not wanting to block on the ECC PAG any longer, what are 
>> the options to move widgets-digsig to REC ASAP?
>> 
>> Some options:
>> 
>> 1. Replace [XMLSig1.1] dependency with XMLSig 1.0. I presume this would 
>> require a new 3-week LC but the CR could be zero-length, presumably no 
>> re-testing would be required, and the only thing blocking PR->REC is the 
>> length of the new CfE that would be needed.
>> 
>> 2. Move the tainted algorithm(s) in XMLSig1.1 to XMLSig1.Next so 
>> XMLSig1.1 is not affected by the PAG and XMLSig1.1 can then continue on 
>> the REC track.
>> 
>> 3. Others?
> 
> An other one was for the Director to decide to move the document forward
> anyway because W-DigSig doesn't depend on ECC.
> 
> Thomas, any suggestion?
> 
> Philippe
> 
> 
>

Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-15 Thread Marcos Caceres 


On Wednesday, December 14, 2011 at 10:31 PM, Marcos Caceres wrote:

> 
> 
> On Wednesday, 14 December 2011 at 21:06, Rigo Wenning wrote:
> 
> > Hi all, 
> > 
> > as the PAG chair of this XMLSEC PAG, let me tell you that support from the 
> > industry in sorting this out was low so far. What I heard through the 
> > grapevine was more or less: "We know, but we can't tell you". 
> > 
> > For the moment, W3C is asking for cost estimates to figure out what most of 
> > the members already know (as they have done the analysis on ECC long ago). 
> > Taking into account the complexity of the subject matter and also the 
> > delays 
> > due to messaging to the AC etc, I'm rather pessimistic about a quick 
> > resolution.
> 
> 
> That's fine. That just makes for a stronger case to put to the Director (or 
> for doing what Artb suggested, and moving the ECC to a future version of XML 
> Dig Sig).
FYI, document is ready to be published as REC:
 
 http://dev.w3.org/2006/waf/widgets-digsig/ 


-- 
Marcos Caceres

[Pointer Lock] Few comments

2011-12-15 Thread Olli Pettay 

Hi all,

few comments about the API

(1)
currently 
http://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.html uses 
VoidCallback which isn't defined anywhere.


I guess there should be something like

void lock (in Element target,
   optional in LockSuccessCallback successCallback,
   optional in LockErrorCallback failureCallback);


[Callback,NoInterfaceObject]
interface LockSuccessCallback {
  void pointerLockSuccess();
};

[Callback,NoInterfaceObject]
interface LockErrorCallback {
  void pointerLockFailure();
};

Or if the new proposed callback syntax is used:
callback LockSuccessCallback = void pointerLockSuccess();
callback LockErrorCallback = void pointerLockFailure();


(2)
"If another element is locked a user agent must transfer the mouse lock 
to the new target and call the pointerlocklost callback for the previous 
target."

There is no such thing as 'pointerlocklost callback'

(3)
"Mouse lock must succeed only if the window is in focus and the 
user-agent is the active application of the operating system"

What window? window object as in web page? Or OS level window?
What if lock is called in some iframe?

(4)
"If the target is removed from the DOM tree after mouse lock is entered 
then mouse lock will be lost."

Should 'pointerlocklost' event be dispatched?




-Olli

[Bug 15210] New: Consider dispatching an event when bufferedAmount drops to 0

2011-12-15 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15210

   Summary: Consider dispatching an event when bufferedAmount
drops to 0
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: olli.pet...@gmail.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Right now the spec has example
socket.onopen = function () {
setInterval(function() {
  if (socket.bufferedAmount == 0)
socket.send(getUpdateData());
}, 50);
  };

That works, sure, but in many cases there shouldn't be a need for such
interval.
Especially in worker context something like:
socket.onemptybuffer = function () {
socket.send(getUpdateData());
  };
could work quite nicely.

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

[Bug 15209] New: send() should not close the connection so easily

2011-12-15 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15209

   Summary: send() should not close the connection so easily
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: olli.pet...@gmail.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


If the connection is slow, it is probably quite easy to fill some buffers, 
which would (possibly) per spec lead to closing the connection.
That is bad. The connection is working, but just a bit slow.

If send() can't temporarily process the data (like buffer it), 
it should, IMO, either throw an exception or perhaps better would be to
return false.

-- 
Configure bugmail: https://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: CfC: add Quota API to WebApps' charter; deadline December 20

2011-12-15 Thread Arthur Barstow 

Hi Kinuko, All,

Besides the Chromium team, I think it would be helpful if other browser 
vendors would state their level of interest for this API (e.g. would 
review drafts, prototype, deploy, etc.).


Kinuko - do you have a commitment for the Editor role and testing 
related tasks e.g. creating a test suite?


-AB


On 12/13/11 7:23 AM, ext Arthur Barstow wrote:

Subject corrected ...

On 12/13/11 7:22 AM, Arthur Barstow wrote:
As IanF mentioned before, Google would like to add a Quota API to 
WebApps' charter and Kinuko has now provided a link to a document 
that provides some details about this API:


   http://wiki.whatwg.org/wiki/Quota

As such, this is a Call for Consensus to add this API to WebApps' 
charter (see [CharterChanges] for latest data on WebApps' charter 
update).


If you have any comments or concerns about this proposal, please send 
them to public-webapps by December 20 at the latest.


As with all of our CfCs, positive response is preferred and 
encouraged and silence will be assumed to be agreement with the 
proposal.


-AB

[CharterChanges] http://www.w3.org/2008/webapps/wiki/CharterChanges


 Original Message 
Subject: Re: Quota API and WebApps [Was: Re: Consolidating 
charter changes]

Date: Tue, 13 Dec 2011 17:22:38 +0900
From: ext Kinuko Yasuda 
To: Arthur Barstow 
CC: public-webapps , Ian Fette 





Hi Arthur,

On Wed, Nov 23, 2011 at 10:20 PM, Arthur Barstow 
mailto:art.bars...@nokia.com>> wrote:


   Hi IanF, All,

   Following up on Quota API vis-à-visCharterChanges wiki [1] ...

   Does the group want to add Quota API to the group's charter? If yes,
   where is a draft/strawman proposal?


We have an early draft for Quota API spec here:
http://wiki.whatwg.org/wiki/Quota

I think we want to add it to the group's charter.

   -AB

   [1] http://www.w3.org/2008/webapps/wiki/CharterChanges

   On 11/8/11 12:37 PM, ext Arthur Barstow wrote:

   During the October 31 meeting, we discussed [1] various
   additions, changes and deletions for WebApps' current charter
   [2]. To consolidate the various proposals, I created the
   following doc:



   My expectation is that Doug will this information when he drafts
   our updated charter.

   Comments on this doc and our future charter welcome. However, if
   we are going to add any new deliverables, I think there should
   be broad agreement on the spec, including prior commitment to
   drive the spec through all of the phases of the process
   including testing and implementations.

   Chaals, IanF - I included some actions/questions for you (mostly
   recorded at the f2f meeting).

   -AB

   [1] http://www.w3.org/2011/10/31-webapps-minutes.html
   [2] http://www.w3.org/2010/webapps/charter/