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

2010-09-01 Thread Mikeal Rogers 
I might attend if there are enough IndexedDB people there.

On Wed, Sep 1, 2010 at 7:28 PM, Jonas Sicking  wrote:

> 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: Seeking agenda items for WebApps' Nov 1-2 f2f meeting

2010-09-01 Thread Jonas Sicking 
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: Seeking agenda items for WebApps' Nov 1-2 f2f meeting

2010-09-01 Thread Pablo Castro 

-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: [XHR] Redirects

2010-09-01 Thread Julian Reschke 

On 02.09.2010 00:00, Darin Fisher wrote:

On Wed, Sep 1, 2010 at 5:19 AM, Julian Reschke mailto:julian.resc...@gmx.de>> wrote:

On 01.09.2010 10:16, Anne van Kesteren wrote:

...

I thought of another reason to want the original XHR object
to be
responsible for following the redirect: the value of a
Location header
may be a relative URL. It would be nice if application
authors did not
have to take care of resolving that manually. (In the case of a
cross-origin
request, the relative URL should be resolved relative to the
URL that was
redirected instead of against the Document.) This seems like
something
that could be easy to mess up.


Yeah, I thought of that. There's location.resolveURL(), but it
does not
take a base URL at the moment. We could add that. Though note that
relative URLs are forbidden in theory.
...


They are in RFC 2616, but not in HTTPbis

().

Best regards, Julian


What does it mean for them to not be part of HTTPbis?  Relative URLs in
Location headers are not uncommon.



Clarifying: they are *forbidden* in RFC 2616 (*), but not in HTTPbis
(), 
so HTTPbis *allows* them now.


BR, Julian

(*) the ABNF doesn't allow them.

Re: [XHR] Redirects

2010-09-01 Thread Bjoern Hoehrmann 
* Darin Fisher wrote:
>>> Though note that relative URLs are forbidden in theory.
>> They are in RFC 2616, but not in HTTPbis ...
>
>What does it mean for them to not be part of HTTPbis?  Relative URLs in
>Location headers are not uncommon.

You missed the double negative.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Re: [XHR] Redirects

2010-09-01 Thread Darin Fisher 
On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren  wrote:

> On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher 
> wrote:
>
>> On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren > >wrote:
>>
>>> This does not work for synchronous requests in a worker.
>>>
>>
>> Hmm, good point.  An alternative design might be a flag that causes
>> .send() to complete once a redirect response is received, but then also
>> provide a
>> method on the XHR object to tell it to now follow the redirect.  This
>> model would work for both synchronous as well as asynchronous.
>>
>
> That seems like the current design, except we currently do not have that
> additional method. I would like to keep it out until it is more clear this
> is a real problem. It would add quite a bit of complexity whereas just
> having this is fairly straightforward.
>
>
The problems I've raised here are real problems that I've observed while
building HTTP implementations for Mozilla and Chromium.  It is easy for good
coders to make these kinds of mistakes.

-Darin



>
>
>  I thought of another reason to want the original XHR object to be
>> responsible for following the redirect:  the value of a Location header
>> may be a relative URL.  It would be nice if application authors did not have
>> to take care of resolving that manually.  (In the case of a cross-origin
>> request, the relative URL should be resolved relative to the URL that was
>> redirected instead of against the Document.)  This seems like something
>> that could be easy to mess up.
>>
>
> Yeah, I thought of that. There's location.resolveURL(), but it does not
> take a base URL at the moment. We could add that. Though note that relative
> URLs are forbidden in theory.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [XHR] Redirects

2010-09-01 Thread Darin Fisher 
On Wed, Sep 1, 2010 at 5:19 AM, Julian Reschke wrote:

> On 01.09.2010 10:16, Anne van Kesteren wrote:
>
>> ...
>>
>>  I thought of another reason to want the original XHR object to be
>>> responsible for following the redirect: the value of a Location header
>>> may be a relative URL. It would be nice if application authors did not
>>> have to take care of resolving that manually. (In the case of a
>>> cross-origin
>>> request, the relative URL should be resolved relative to the URL that was
>>> redirected instead of against the Document.) This seems like something
>>> that could be easy to mess up.
>>>
>>
>> Yeah, I thought of that. There's location.resolveURL(), but it does not
>> take a base URL at the moment. We could add that. Though note that
>> relative URLs are forbidden in theory.
>> ...
>>
>
> They are in RFC 2616, but not in HTTPbis (<
> http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-11.html#rfc.section.9.4
> >).
>
> Best regards, Julian
>

What does it mean for them to not be part of HTTPbis?  Relative URLs in
Location headers are not uncommon.

-Darin

[Bug 10527] New: [IndexedDB] Result of IDBCursor.remove and update unspecified.

2010-09-01 Thread bugzilla 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10527

   Summary: [IndexedDB] Result of IDBCursor.remove and update
unspecified.
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: andr...@google.com
ReportedBy: jor...@chromium.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


The result of IDBCursor.remove and update unspecified.

I assume these are supposed to have a null result?

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

Re: [XHR] Redirects

2010-09-01 Thread Julian Reschke 

On 01.09.2010 10:16, Anne van Kesteren wrote:

...

I thought of another reason to want the original XHR object to be
responsible for following the redirect: the value of a Location header
may be a relative URL. It would be nice if application authors did not
have to take care of resolving that manually. (In the case of a
cross-origin
request, the relative URL should be resolved relative to the URL that was
redirected instead of against the Document.) This seems like something
that could be easy to mess up.


Yeah, I thought of that. There's location.resolveURL(), but it does not
take a base URL at the moment. We could add that. Though note that
relative URLs are forbidden in theory.
...


They are in RFC 2616, but not in HTTPbis 
().


Best regards, Julian

[widgets] Draft agenda for 2 September 2010 voice conf

2010-09-01 Thread Arthur Barstow 
 Below is the draft agenda for the September 2 Widgets Voice Conference 
(VC).


Inputs and discussion before the VC on all of the agenda topics via 
public-webapps is encouraged (as it can result in a shortened meeting). 
Please address Open/Raised Issues and Open Actions before the meeting:


 http://www.w3.org/2008/webapps/track/products/8

Minutes from the last VC:

  http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0475.html

-Art Barstow

Agenda:

1. Review and tweak agenda

2. Announcements

a. TPAC registration

3. Packaging and Configuration spec
 http://dev.w3.org/2006/waf/widgets/

a. Test suite status
 http://dev.w3.org/2006/waf/widgets/test-suite/

b. Implementation report progress
  http://dev.w3.org/2006/waf/widgets/imp-report/

4. Digital Signature spec
 http://dev.w3.org/2006/waf/widgets-digsig/

a. Test suite status
 http://dev.w3.org/2006/waf/widgets-digsig/test-suite/

b. Implementation report progress
 http://dev.w3.org/2006/waf/widgets-digsig/imp-report/

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

a. Normative changes since 22-Dec-2009 CR was published

b. Call for Consensus to publish new Last Call Working Draft

6. AOB

Logistics:

 Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 
Boston; 06:00 Seattle

 Duration: 90 minutes max
 Zakim Bridge:+1.617.761.6200, +33.4.26.46.79.03 or +44.203.318.0479
 PIN: 9231 ("WAF1");
 IRC: channel = #wam; irc://irc.w3.org:6665 ; 
http://cgi.w3.org/member-bin/irc/irc.cgi

 Confidentiality of minutes: Public

Re: [XHR] Redirects

2010-09-01 Thread Anne van Kesteren 
On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher   
wrote:
On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren  
wrote:

This does not work for synchronous requests in a worker.


Hmm, good point.  An alternative design might be a flag that causes  
.send() to complete once a redirect response is received, but then also  
provide a
method on the XHR object to tell it to now follow the redirect.  This  
model would work for both synchronous as well as asynchronous.


That seems like the current design, except we currently do not have that  
additional method. I would like to keep it out until it is more clear this  
is a real problem. It would add quite a bit of complexity whereas just  
having this is fairly straightforward.




I thought of another reason to want the original XHR object to be
responsible for following the redirect:  the value of a Location header  
may be a relative URL.  It would be nice if application authors did not  
have to take care of resolving that manually.  (In the case of a  
cross-origin

request, the relative URL should be resolved relative to the URL that was
redirected instead of against the Document.)  This seems like something  
that could be easy to mess up.


Yeah, I thought of that. There's location.resolveURL(), but it does not  
take a base URL at the moment. We could add that. Though note that  
relative URLs are forbidden in theory.



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

Re: [XHR] Redirects

2010-09-01 Thread Darin Fisher 
On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren wrote:

> On Tue, 31 Aug 2010 22:51:19 +0200, Darin Fisher 
> wrote:
>
>> If instead, we had an API for auditing redirects (perhaps an "onredirect"
>> event), then we could let developers handle that event and call
>> preventDefault if they want to stop redirect processing.  Otherwise, the
>> redirect would be processed normally.  The result being that application
>> authors would be guided away from following redirects manually, and hence
>> they would avoid the problems I've described above.
>>
>
> This does not work for synchronous requests in a worker.


Hmm, good point.  An alternative design might be a flag that causes .send()
to complete once a redirect response is received, but then also provide a
method on the XHR object to tell it to now follow the redirect.  This model
would work for both synchronous as well as asynchronous.



> If we are okay with that it seems an acceptable alternative. However,
> redirects are processed before the object reaches HEADERS_RECEIVED (as
> otherwise it would reach that several times) so HTTP headers et cetera are
> not available yet. Given that, and given that you want that information, you
> would always invoke preventDefault(), defeating the purpose of having an
> event.
>
>
It does seem like you'd want to see the headers corresponding to the
redirect.

I thought of another reason to want the original XHR object to be
responsible for following the redirect:  the value of a Location header may
be a relative URL.  It would be nice if application authors did not have to
take care of resolving that manually.  (In the case of a cross-origin
request, the relative URL should be resolved relative to the URL that was
redirected instead of against the Document.)  This seems like something that
could be easy to mess up.

-Darin