On Fri, Jun 3, 2011 at 4:15 PM, Andrew Wilson wrote:
>
>
> On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard wrote:
>>
>> On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson wrote:
>> > significant motivation. The stated motivations for breaking this API
>> > don't
>> > seem compelling to me given the exi
On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard wrote:
> On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson wrote:
> > significant motivation. The stated motivations for breaking this API
> don't
> > seem compelling to me given the existence of backwards-compatible
> > alternatives.
>
> This proposal i
> On Fri, Jun 3, 2011 at 6:02 PM, Jonas Sicking wrote:
>> e) Keep "MessagePort[] ports" the way it is but deprecate it.
>
> For anyone not looking closely at the IDL while reading this, this
> means deprecating (for whatever value "deprecate" has on the web) the
> ports array in MessageEvent--not
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson wrote:
> significant motivation. The stated motivations for breaking this API don't
> seem compelling to me given the existence of backwards-compatible
> alternatives.
This proposal is backwards-compatible. If the argument is an array,
nothing change
On Fri, Jun 3, 2011 at 2:54 PM, Kenneth Russell wrote:
> On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson wrote:
>>
>>
>> On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
>>>
>>> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
>>> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson wrote:
>
>
> On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
>>
>> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
>> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
>> >> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov
>> >> wrot
On Fri, Jun 3, 2011 at 2:25 PM, Dmitry Lomov wrote:
> (I am answering on multiple points - I do not want to fork the thread)
>
> On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
>>
>> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
>> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson wrote:
>
>
> On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
>
>> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
>> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
>> >> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov
>> wrote:
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
> >> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov
> wrote:
> >>> a) Recursive transfer lists. Allow arbitrary objects, not on
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
> On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
>> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov wrote:
>>> a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
>>> to appear in transfer lists. ArrayBuffers t
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12883
Summary: In section headed: Interpreting an event stream Step
4: "If the event name buffer has a value other than
the empty string, change the type of the newly created
event
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov wrote:
>> a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
>> to appear in transfer lists. ArrayBuffers that are under objects in
>> transfer lists are transferred, ot
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov wrote:
> a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
> to appear in transfer lists. ArrayBuffers that are under objects in
> transfer lists are transferred, others are cloned.
This again causes the same forwards-compa
- Original Message -
From: "Rich Tibbett"
To: "David Dahl"
Cc: public-webapps@w3.org
Sent: Friday, June 3, 2011 6:25:15 AM
Subject: Re: Request for feedback: DOMCrypt API proposal
> I wonder whether the problem is actually just one of generating
sufficiently cryptographically secure P
Hi Philippe,
One more request. I need some way of testing the RFC3490 ToASCII
algorithm. In widgets, we are currently using an icann url to do this:
http://हिन्दी.idn.icann.org"/>
http://उदाहरण.परीक्षा"; subdomains="true"/>
We basically need some kind of equivalent subdomains to the above.
- Original Message -
From: "Jonas Sicking"
To: "Adam Barth"
Cc: "David Dahl" , public-webapps@w3.org
Sent: Friday, June 3, 2011 12:31:48 AM
Subject: Re: Request for feedback: DOMCrypt API proposal
> I agree that keychains and the like seems like a can of worms. However
something that w
- Original Message -
From: "Adam Barth"
To: "David Dahl"
Cc: public-webapps@w3.org
Sent: Thursday, June 2, 2011 8:57:11 PM
Subject: Re: Request for feedback: DOMCrypt API proposal
> Really, the API should be algorithm agnostic. We can discuss separately
> which algorithms to provide.
On Thu, Jun 2, 2011 at 11:44 PM, Dmitry Lomov wrote:
>
>
> On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking wrote:
>
>> On Thu, Jun 2, 2011 at 4:41 PM, David Levin wrote:
>> >
>> >
>> > On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking wrote:
>> >>
>> >> On Thu, Jun 2, 2011 at 2:01 PM, David Levin
On 6/3/11 1:39 PM, Arthur Barstow wrote:
Hi Marcos - given this spec is in the Candidate Recommendation state,
before a CfC to publish a new LCWD is started, I think it would be
helpful if you provided a list of the changes you propose and a short
summary for each change. WDYT?
I don't have a st
On 6/3/11 3:27 PM, Philippe Le Hegaret wrote:
On Thu, 2011-06-02 at 20:15 +0200, Marcos Caceres wrote:
On Thu, Jun 2, 2011 at 5:50 PM, Philippe Le Hegaret wrote:
On Thu, 2011-06-02 at 17:47 +0200, Marcos Caceres wrote:
Hi Philippe,
Just wondering if we have different port support yet on test-
On Thu, 2011-06-02 at 20:15 +0200, Marcos Caceres wrote:
> On Thu, Jun 2, 2011 at 5:50 PM, Philippe Le Hegaret wrote:
> > On Thu, 2011-06-02 at 17:47 +0200, Marcos Caceres wrote:
> >> Hi Philippe,
> >> Just wondering if we have different port support yet on test-w3c.org?
> >> Would be nice to at l
On 6/3/11 6:02 AM, Margarita Podskrobko wrote:
In this particular case, the user might be not aware that there is any
this kind of addon running in browser and changing the value of Origin
header.
If the user doesn't know what addons are running in the browser, then
the user is screwed. Addon
Hi Marcos - given this spec is in the Candidate Recommendation state,
before a CfC to publish a new LCWD is started, I think it would be
helpful if you provided a list of the changes you propose and a short
summary for each change. WDYT?
I don't have a strong opinion on where the list of chang
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking wrote:
> On Thu, Jun 2, 2011 at 4:41 PM, David Levin wrote:
> >
> >
> > On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking wrote:
> >>
> >> On Thu, Jun 2, 2011 at 2:01 PM, David Levin wrote:
> >> >
> >> >
> >> > On Thu, Jun 2, 2011 at 1:27 PM, Glenn Ma
The spec says:
""At runtime, when a network request is made from within the widget
execution scope, the user agent matches it against the rules defined
above, accepting it if it matches and blocking it if it doesn't."""
However, *blocking* is not defined. This has lead to inconstant behavior
I wonder whether the problem is actually just one of generating
sufficiently cryptographically secure PRNGs or whether there are real
benefits to creating a full-blown UA-based Crypto API and the can of
worms that might open.
There was a proposal on the WHATWG back in February for producing a
> >> How would you set the "Origin" header?
> >>
> >
> > I have figured out at least one unexpected and surprisingly easy way to do
> > it in Firefox. There is a firefox addon available , which lets set Origin
> > header to any value. Addon is available from the following
> > link: https://addon
On Fri, Jun 3, 2011 at 2:44 AM, Dmitry Lomov wrote:
>> Now show me the code needed to send a message which contains one big
>> buffer from you that you want to transfer, along with some data that
>> you got from some other piece of code and which you do not want to
>> modify and which may or may n
28 matches
Mail list logo
