Re: WebApps' new charter has been approved

[Arthur Barstow]

On 4/27/12 10:51 AM, ext Mounir Lamouri wrote:

The "Screen Orientation API" is now listed as "View Orientation API".
I do not really understand why this change has been made. I could 
understand that "Screen Orientation" might be confusing with 
"DeviceOrientation" but "View Orientation" isn't really making that 
easier to understand.
In addition, the "Screen Orientation API" is about getting and locking 
the entire device's screen, not the application view. Using "View" 
instead of "Screen" might make this intent very unclear.


What was the reasons behind this renaming?


During Nokia's internal review of the proposed charter, I got some 
feedback that the use of screen here was a bit confusing. (One of the 
comments was that "current mobile devices do not change the orientation 
of the screen in an OS sense, but of the individual applications"). As 
such, during AC's charter review, I proposed changing the name to View 
Orientation API.


I think we all agree the primary interest is that the technical aspects 
of the spec proceed (and that ratholing/bikeshedding on the title isn't 
a high priority). As such, I changed the title in PubStatus to Screen 
Orientation API to match the latest ED.


Sorry for the confusion.

-AB

Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer

[Arun Ranganathan]

On Apr 27, 2012, at 1:28 AM, Anne van Kesteren wrote:

> On Fri, 27 Apr 2012 00:13:42 +0200, Arun Ranganathan 
>  wrote:
>> The constructor will switch to use ArrayBufferView in lieu of ArrayBuffer, 
>> but the read method exposed on FileReader and FileReaderSync will read files 
>> into memory as ArrayBuffers.
> 
> Since the constructor is not widely deployed yet would it not be better to 
> stick to ArrayBufferView exclusively, just like XMLHttpRequest.send()?


The Blob constructor will already use ArrayBufferView.  Above, do you mean, 
have a method of the sort FileReader.readAsArrayBufferView or something like 
that?  

*.readAsArrayBuffer is already deployed, and it might be weird to force a view 
on an ArrayBuffer when read into memory.

-- A*


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

Re: [whatwg] [Server-Sent Events] Infinite reconnection clarification

[Tab Atkins Jr.]

On Fri, Apr 27, 2012 at 4:12 AM, Odin Hørthe Omdal  wrote:
> I think I should do a TLDR since I didn't really get any answers:
>
> 1. Should EventSource *ever* time out once it has once been connected?
> 2. What do browsers do today? What do you think is a good thing to do?
>
> I tried Opera, Firefox and Chromium for question 2.
>
> Opera: Gives up after 2-3 minutes.
> Firefox: Gives up after ~15 minutes.
> Chromium: Doesn't ever give up. Longer and longer retry intervals, upper
> limit (I think) of 1 minute between each retry.

I think the best thing for users is infinite reconnect with
exponential backoff (the Chrome behavior).  This gives the page the
best chance of "just working" when the user gets back into an area
with connection.

Waking up the radio once a minute isn't bad, if we can coalesce all
our EventSource requests to use the same window.

~TJ

Re: WebApps' new charter has been approved

[Mounir Lamouri]

On 4/27/12 3:07 PM, Arthur Barstow wrote:

Hi All,

Yesterday the Director announced WebApps' new charter [Charter] was
approved so thanks to all that helped with the chartering effort.

I added all of the new specs to our [PubStatus] page and made a couple
of tweaks to the group's [WorkMode] wiki.


Hi,

The "Screen Orientation API" is now listed as "View Orientation API".
I do not really understand why this change has been made. I could 
understand that "Screen Orientation" might be confusing with 
"DeviceOrientation" but "View Orientation" isn't really making that 
easier to understand.
In addition, the "Screen Orientation API" is about getting and locking 
the entire device's screen, not the application view. Using "View" 
instead of "Screen" might make this intent very unclear.


What was the reasons behind this renaming?

Thanks,
--
Mounir

Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer

[Glenn Maynard]

On Fri, Apr 27, 2012 at 12:28 AM, Anne van Kesteren wrote:

> On Fri, 27 Apr 2012 00:13:42 +0200, Arun Ranganathan <
> aranganat...@mozilla.com> wrote:
>
>> The constructor will switch to use ArrayBufferView in lieu of
>> ArrayBuffer, but the read method exposed on FileReader and FileReaderSync
>> will read files into memory as ArrayBuffers.
>>
>
> Since the constructor is not widely deployed yet would it not be better to
> stick to ArrayBufferView exclusively, just like XMLHttpRequest.send()?


I think he's saying that the ctor (inputting data) will use ArrayBufferView
only, but FileReader (*outputting* data) returns an ArrayBuffer, like XHR's
arraybuffer response entity body.

I wish typed arrays could be fixed so ArrayBuffer is itself an
ArrayBufferView, to fix this inconsistency, but I think there are one or
two places in the API where it would break compat...

-- 
Glenn Maynard

WebApps' new charter has been approved

[Arthur Barstow]

Hi All,

Yesterday the Director announced WebApps' new charter [Charter] was 
approved so thanks to all that helped with the chartering effort.


I added all of the new specs to our [PubStatus] page and made a couple 
of tweaks to the group's [WorkMode] wiki.


As is done with our "old" specs, our expectation is that the Editors of 
the new specs will lead their spec's standardization effort (e.g. 
responding to questions, reflecting comments in the spec, preparing 
specs for publication in /TR/, testing, etc.). Since most of the new 
spec Editors are new to editing W3C specs, if you have any questions 
about re the Editor roles and tasks, please feel free to ask Chaals, 
Doug or I. (Depending on the need, we may put together some Newbie 
Editor type info.)


I believe some of the new specs already have some implementation 
experience so if that is the case for your spec, we should start working 
toward a CfC for First Public Working Draft.


-Cheers, Art and Chaals

[Charter] 
[PubStatus] 
[WorkMode] 

Re: [Server-Sent Events] Infinite reconnection clarification

[Odin Hørthe Omdal]

I think I should do a TLDR since I didn't really get any answers:

1. Should EventSource *ever* time out once it has once been connected?
2. What do browsers do today? What do you think is a good thing to do?

I tried Opera, Firefox and Chromium for question 2.

Opera: Gives up after 2-3 minutes.
Firefox: Gives up after ~15 minutes.
Chromium: Doesn't ever give up. Longer and longer retry intervals, upper  
limit (I think) of 1 minute between each retry.




And the TL version follows:

On Tue, 17 Apr 2012 16:44:56 +0200, Odin Hørthe Omdal   
wrote:



If I understand correcly, the spec expects the implementation to keep
reconnecting indefinitely, when the network cable is yanked. It is a
strong feeling, but it'd be nice to get it clarified in plain text in the
spec.

Clients will reconnect if the connection is closed; a client can be  
told to stop reconnecting using the HTTP 204 No Content response code.



CLOSED (numeric value 2)
The connection is not open, and the user agent is not trying to  
reconnect. Either there was a fatal error or the close() method was  
invoked.


The task that the networking task source places on the task queue once  
the fetching algorithm for such a resource (with the correct MIME type)  
has completed must cause the user agent to asynchronously reestablish  
the connection. This applies whether the connection is closed  
gracefully or unexpectedly. It doesn't apply for the error conditions  
listed below.



And this is the place a small clarification could come in handy:

Any other HTTP response code not listed here, and any network error  
that prevents the HTTP connection from being established in the first  
place (e.g. DNS errors), must cause the user agent to fail the  
connection.


Maybe "Network errors after a successfully established connection must
cause the user agent to try reestablishing the connection indefinitely."

Or something better. At least, make it clear what is going to happen. :-)


On that note, it'd also be nice to hear what the other vendors do with  
the

connection. It seems like both Firefox and Chromium has an exponential
fallback with a max-value between the reconnection tries. The first tries
will probably respect the given *reconnection time*, but after a while
that'll be too often.

I tried yanking the network for 10+ minutes, and when I put the cable in
again, both Firefox and Chromium used 25 seconds to reconnect. When only
yanking it for one minute, the reconnection was much faster (2-5  
seconds).

This with *reconnection time* set to 500ms.




--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

Re: CORS in Google App Engine

[Anne van Kesteren]

On Thu, 26 Apr 2012 17:46:27 +0200, Bruce Sherwood  
 wrote:

(My apologies if this appears twice, but it looks like my original
posting got lost in the process of subscribing.)


This is a forum to discuss standards, not one for how to use them in  
particular environments. I suggest you try http://stackoverflow.com/



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

CORS in Google App Engine

[Bruce Sherwood]

(My apologies if this appears twice, but it looks like my original
posting got lost in the process of subscribing.)

I've searched unsuccessfully for more help on enabling CORS in a
Python-based Google App Engine web site. I want to enable cross-origin
access to a folder containing jpeg files (to be used as textures in a
WebGL application). What I found as an example for an enable script is
this (where I've added the import line; the name of the Python file is
enablecors.py):


from google.appengine.ext import webapp
class CORSEnabledHandler(webapp.RequestHandler):
 def get(self):
   self.response.headers.add_header("Access-Control-Allow-Origin", "*")
   self.response.headers['Content-Type'] = 'text/csv'
   self.response.out.write(self.dump_csv())


I'm guessing that my app.yaml file should have an entry like the
following, where the folder /untrusted/testimages contains the ".jpg"
files:

- url: /untrusted/testimages/.*
  script: ide/enablecors.py

Because there is some documentation that implies that the GAE will by
default do the right thing based on the ".jpg" file extension, I'm
guessing that I can (should?) comment out the last two lines of the
little Python program. But if that's not the case, I'm guessing that
the next-to-the last statement should be

self.response.headers['Content-Type'] = 'image/jpeg'

But then would should the final statement be?

A minor point: I tried to say

- url: /untrusted/testimages/.*
  static_dir: untrusted/testimages
  script: ide/enablecors.py

because I thought that was the right way to handle images, but the GAE
launcher complains about this.

I'd really appreciate some very explicit details on how to set this
up, as none of the various permutations I've tried have worked.

The context is GlowScript (glowscript.org), which allows even
nonexpert programmers to write JavaScript or CoffeeScript programs to
generate 3D animations using WebGL. The programs are developed in the
cloud and can run in the cloud, but one can export the code to one's
own web site. In that case, however, CORS needs to be enabled so that
when the program runs outside glowscript.org the program can still get
at the images stored at glowscript.org.

Bruce Sherwood

CORS in Google App Engine

[Bruce Sherwood]

I've searched unsuccessfully for more help on enabling CORS in a
Python-based Google App Engine web site. I want to enable cross-origin
access to a folder containing jpeg files (to be used as textures in a
WebGL application). What I found as an example for an enable script is
this (where I've added the import line; the name of the Python file is
enablecors.py):

from google.appengine.ext import webapp

class CORSEnabledHandler(webapp.RequestHandler):
  def get(self):
self.response.headers.add_header("Access-Control-Allow-Origin", "*")
self.response.headers['Content-Type'] = 'text/csv'
self.response.out.write(self.dump_csv())

I'm guessing that my app.yaml file should have an entry like the
following, where the folder /untrusted/testimages contains the ".jpg"
files:

- url: /untrusted/testimages/.*
  script: untrusted/enablecors.py

Because there is some documentation that implies that the GAE will by
default do the right thing based on the ".jpg" file extension, I'm
guessing that I can (should?) comment out the last two lines of the
little Python program. But if that's not the case, I'm guessing that
the next-to-the last statement should be

self.response.headers['Content-Type'] = 'image/jpeg'

But then would should the final statement be?

A minor point: I tried to say

- url: /untrusted/testimages/.*
  static_dir: untrusted/testimages
  script: untrusted/enablecors.py

because I thought that was the right way to handle images, but the GAE
launcher complains about this.

I'd really appreciate some very explicit details on how to set this
up, as none of the various permutations I've tried have worked. The
context is GlowScript (glowscript.org), which allows even nonexpert
programmers to write JavaScript or CoffeeScript programs to generate
3D animations using WebGL. The programs are developed in the cloud and
can run in the cloud, but one can export the code to one's own web
site. In that case, however, CORS needs to be enabled so that when the
program runs outside glowscript.org the program can still get at the
images stored at glowscript.org.

Bruce Sherwood

Re: Request for FormData.remove() method

[Ivan Enderlin @ Hoa]

Hi David, Anne and others,

On 26/04/12 13:55, Anne van Kesteren wrote:
On Wed, 18 Apr 2012 20:07:57 +0200, Bronislav Klučka 
 wrote:
FormData can be useful not only to be sent via XHR, but essentially 
to hold form values easily, e.g. you can have settings form (that you 
do not need to send any where = you do not need to store it or you 
store it in e.g. IndexDb), then get this settings and alter 
application according to this settings... Instead of doing exactly 
the same, but manually


Why would you not simply use a JavaScript object for this?
I recently met the following use case: create a FormData object from a 
, send it to some listeners that can actually edit this 
FormData, to finally send it via a XHR to the server. Listeners can add 
some data (with FormData.append) but I would like them to be able to 
edit or remove data (for security concerns, or whatever else). The only 
solution I found is to create a new FormData-like object that mimics the 
real one but with the addition of some functions. In fact, I gently 
expose the “fields” object or array and transform it to a real FormData 
object when calling toString() or something like that.

By the way, some features are clearly missing on the FormData interface.

Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/