ISSUE-134 (optional useCapture): Consider making useCapture parameter of add/removeEventListener optional [DOM3 Events]

[Web Applications Working Group Issue Tracker]

ISSUE-134 (optional useCapture): Consider making useCapture parameter of 
add/removeEventListener optional [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/134

Raised by: Doug Schepers
On product: DOM3 Events

Sergey Ilinsky 
:
[[
There are modern browsers that made 3rd argument in the
addEventListener/removeEventListener be optional. Is this a legal step?
If I understand correctly, specification requires 3rd argument to be passed,
thus the new behaviour not backed by the change
in specification only destabilizes web as a platform.

Personally, I like the behaviour, but cannot use it as long as not every
browser does that.
]]

Re: [IndexedDB] Calling setVersion while already in a setVersion transaction

[Jonas Sicking]

On Wed, Sep 29, 2010 at 6:12 AM, Jeremy Orlow  wrote:
> What should we do when setVersion is called while a setVersion transaction
> is currently active?
> Off the top of my head, I can think of two behaviors we might want to spec:
>  1) Have the subsequent setVersion simply throw an error.  2) Have the
> subsequent setVersion adopt the existing setVersion transaction and change
> the version.  (i.e. whatever the last setVersion call sets as the version
> string will win.)  Any others?  What do you guys think is the most sane
> behavior?

My initial reaction was

3) Schedule another version transaction which is started after the
currently running version transaction (and any other already scheduled
transactions) are done running.

That was actually my initial reaction, though that is biased by what
our implementation naturally would do unless special care is taken to
do something else.

In general I don't feel strongly either way and am fine with all
currently proposed solutions.

/ Jonas

Re: CfC: First Public Working Draft of Web DOM Core; deadline October 2

[Arthur Barstow]

 On 9/25/10 7:29 AM, Barstow Art (Nokia-CIC/Boston) wrote:

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

Support!

-ArtB

Re: [CORS] Suggested HTTP error codes on forbidden origin, unsupported method, etc.?

[Vladimir Dzhuvinov]

On 29 September 2010 13:48, Anne van Kesteren  wrote:
> On Sun, 26 Sep 2010 12:01:59 +0200, Vladimir Dzhuvinov
>  wrote:
>>
>> I looked at various CORS examples, but they were not particularly
>> instructional on how the server should respond if the origin is not
>> allowed or some other check fails. The CORS spec also seems to
>> deliberately avoid this and leave it to the implementers.
>>
>> For my CORS servlet filter I'm planning to respond with
>>
>> HTTP 403 Forbidden - on a origin that is not allowed
>> HTTP 405 Method not allowed - on an unsupported method
>>
>> Does this make sense?
>>
>> How should the server respond if it receives a custom header that is
>> not listed as supported?
>
> I suppose we could give advice, but it does not really matter as the client
> will always treat it as a network error to make it indistinguishable from
> other failures.

Yes, I see now. I just had this uncertainty, when I was coding the
filter, as to how to respond sensibly in case of a CORS exception.
While terminating the request silently wouldn't matter to end users, I
thought providing a meaningful error code and message might help
client-side developers to debug CORS calls with tools like FireBug (at
least, that helped debugging my own apps ;-)

-- 
Vladimir Dzhuvinov :: software.dzhuvinov.com

Re: [IndexedDB] Calling setVersion while already in a setVersion transaction

[Shawn Wilsher]

On 9/29/2010 6:12 AM, Jeremy Orlow wrote:

Off the top of my head, I can think of two behaviors we might want to spec:
  1) Have the subsequent setVersion simply throw an error.  2) Have the
subsequent setVersion adopt the existing setVersion transaction and change
the version.  (i.e. whatever the last setVersion call sets as the version
string will win.)  Any others?  What do you guys think is the most sane
behavior?
I think (2) is most consistent with how transactions work in other 
places.  I think it's sane too.  I can't come up with a good reason why 
we'd throw for subsequent setVersion calls either.


Thinking about it some more, this might make sense for someone who has 
had more than one version change.  They could first update the the 
version from "1" to "2", and then from "2" to "3".  Since it's possible 
that clients visiting the site could be on any of these three versions, 
it makes sense to have functions that only go from the previous version 
to the next, otherwise you'll end up with lots of logic to deal with 
every version combination.  Doing this all in the same transaction seems 
to make sense to me.


Cheers,

Shawn



smime.p7s
Description: S/MIME Cryptographic Signature

[IndexedDB] Calling setVersion while already in a setVersion transaction

[Jeremy Orlow]

What should we do when setVersion is called while a setVersion transaction
is currently active?

Off the top of my head, I can think of two behaviors we might want to spec:
 1) Have the subsequent setVersion simply throw an error.  2) Have the
subsequent setVersion adopt the existing setVersion transaction and change
the version.  (i.e. whatever the last setVersion call sets as the version
string will win.)  Any others?  What do you guys think is the most sane
behavior?

J

Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting

[Arthur Barstow]

 I added the following slots for November 2:

[[
http://www.w3.org/2008/webapps/wiki/TPAC2010#Tuesday.2C_November_2

13:30-15:00: Indexed DB
15:30-16:30: Indexed DB
16:30-18:00: File * APIs
]]

Of course we can fine-tune the times as needed.

Arun - we reserved a speaker phone for remote participants for both days.

-Art Barstow

On 9/28/10 5:45 PM, ext Eric Uhrhane wrote:

Works fine for me.  I'll be there all of Monday and Tuesday.  Due to
jetlag morning vs. afternoon's probably irrelevant to me, as I won't
have any idea what time it is ;'>.

On Tue, Sep 28, 2010 at 2:30 PM, Jonas Sicking  wrote:

The later the better for me. If we can make it after noon I'll be
there for sure.

/ Jonas

On Tue, Sep 28, 2010 at 1:37 PM, Jeremy Orlow  wrote:

I'm OK with any time slot.

On Tue, Sep 28, 2010 at 8:57 PM, Arthur Barstow
wrote:

  Hi All,

Currently, no one has requested a specific day + time slot for any of the
proposed topics:

  http://www.w3.org/2008/webapps/wiki/TPAC2010

When our IndexedDB participants agree on a time slot on Tuesday the 2nd,
I'll add it to the agenda. Pablo, Jonas, Jeremy - please propose a time.

Day + time slot proposals for the agenda topics already proposed are also
welcome (as are proposals for additional topics).

-Art Barstow

On 9/28/10 3:28 PM, ext Pablo Castro wrote:

It looks like there will be good critical mass for IndexedDB discussions,
so I'll try to make it as well. Tuesday would be best for me as well for an
IndexedDB meeting so I can travel on Sunday/Monday.

-pablo

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, September 28, 2010 10:53 AM
To: Jeremy Orlow
Cc: Pablo Castro; art.bars...@nokia.com; public-webapps
Subject: Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting

I'm not 100% sure that I'll make TPAC this year, but if I do, I likely
won't make monday. So a tuesday schedule would fit me better too.

/ Jonas

On Tue, Sep 28, 2010 at 8:36 AM, Jeremy Orlowwrote:

Is it possible to schedule IndexedDB for Tuesday?  I'm pretty sure that
I
can be there then, but Monday is more up in the air at this moment.
Thanks!
Jeremy
On Thu, Sep 2, 2010 at 3:28 AM, Jonas Sickingwrote:

I'm hoping to be there yes. Especially if we'll get a critical mass of
IndexedDB contributors.

/ Jonas

On Wed, Sep 1, 2010 at 7:18 PM, Pablo
Castro
wrote:

-Original Message-
From: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow
Sent: Tuesday, August 31, 2010 4:32 AM


The WebApps WG will meet face-to-face November 1-2 as part of the
W3C's
2010 TPAC meeting week [TPAC].

I created a stub agenda item page and seek input to flesh out
agenda:

http://www.w3.org/2008/webapps/wiki/TPAC2010

[TPAC] includes a link to the Registration page, a detailed schedule
of
the group meetings, and other useful information.

The registration fee is 40€ per day and will increase to 120€ per
day
after October 22.

-Art Barstow

[TPAC] http://www.w3.org/2010/11/TPAC/

For folks working on IndexedDB, are you guys planning on attending the
TPAC? Given the timing of the event it may be a great opportunity to
get
together and iron out a whole bunch of issues at once. It would be
good to
know ahead of time so we can all make plans if we have critical mass.

Thanks
-pablo

Re: [CORS] Suggested HTTP error codes on forbidden origin, unsupported method, etc.?

[Anne van Kesteren]

On Sun, 26 Sep 2010 12:01:59 +0200, Vladimir Dzhuvinov  
 wrote:

I looked at various CORS examples, but they were not particularly
instructional on how the server should respond if the origin is not
allowed or some other check fails. The CORS spec also seems to
deliberately avoid this and leave it to the implementers.

For my CORS servlet filter I'm planning to respond with

HTTP 403 Forbidden - on a origin that is not allowed
HTTP 405 Method not allowed - on an unsupported method

Does this make sense?

How should the server respond if it receives a custom header that is
not listed as supported?


I suppose we could give advice, but it does not really matter as the  
client will always treat it as a network error to make it  
indistinguishable from other failures.



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