Re: FormData and BlobBuilder - duplication of functionality?

[Jonas Sicking]

On Tue, Apr 13, 2010 at 7:35 PM, Michael Nordman  wrote:
> Good question. Let me ask you one. What value should you use for the
> content-type header? That value needs to contain the boundary string. You
> need to know that to xhr.send the data in a way that looks like a form
> submission. Just sending the blob will be "off by one" and the server side
> won't understand it.

There seems to be general agreement (based on various discussions here
and on whatwg) that the .type property should be moved to the Blob
interface. So Blobs will have a content-type. So this problem should
be taken care of.

/ Jonas

Re: FormData and BlobBuilder - duplication of functionality?

[Michael Nordman]

Good question. Let me ask you one. What value should you use for the
content-type header? That value needs to contain the boundary string. You
need to know that to xhr.send the data in a way that looks like a form
submission. Just sending the blob will be "off by one" and the server side
won't understand it.

Another way to deal with that would be to expose a FormData.boundary
attribute. In my made up use case, callers would have to store the boundary
out of band from the blob, and use it to make a properly formed content-type
header value when xhr.send'ing the blob.

Another reason isn't so much a "need"... but to make the programming
interface symmetrical and hopefully easier to understand and use.


On Tue, Apr 13, 2010 at 6:03 PM, Jonas Sicking  wrote:

> On Tue, Apr 13, 2010 at 5:53 PM, Michael Nordman 
> wrote:
> >
> >
> > On Tue, Apr 13, 2010 at 5:39 PM, Jonas Sicking  wrote:
> >>
> >> On Tue, Apr 13, 2010 at 5:34 PM, Michael Nordman 
> >> wrote:
> >> > Hmmm... maybe FormData could have a toBlob() method, and an inverse
> >> > means of
> >> > initializing a FormData object with a properly encoded Blob.
> >>
> >> What's the use case? ;)
> >
> > Persisting FormData and reconstituting it at a later time. For example
> when
> > offline then back online.
>
> Why would you need to recode into a FormData object though? You can
> submit a Blob using XHR the same way you can submit a FormData.


> / Jonas
>

Re: FormData and BlobBuilder - duplication of functionality?

[Jonas Sicking]

On Tue, Apr 13, 2010 at 5:53 PM, Michael Nordman  wrote:
>
>
> On Tue, Apr 13, 2010 at 5:39 PM, Jonas Sicking  wrote:
>>
>> On Tue, Apr 13, 2010 at 5:34 PM, Michael Nordman 
>> wrote:
>> > Hmmm... maybe FormData could have a toBlob() method, and an inverse
>> > means of
>> > initializing a FormData object with a properly encoded Blob.
>>
>> What's the use case? ;)
>
> Persisting FormData and reconstituting it at a later time. For example when
> offline then back online.

Why would you need to recode into a FormData object though? You can
submit a Blob using XHR the same way you can submit a FormData.

/ Jonas

Re: FormData and BlobBuilder - duplication of functionality?

[Michael Nordman]

On Tue, Apr 13, 2010 at 5:39 PM, Jonas Sicking  wrote:

> On Tue, Apr 13, 2010 at 5:34 PM, Michael Nordman 
> wrote:
> > Hmmm... maybe FormData could have a toBlob() method, and an inverse means
> of
> > initializing a FormData object with a properly encoded Blob.
>
> What's the use case? ;)
>

Persisting FormData and reconstituting it at a later time. For example when
offline then back online.

/ Jonas

Re: FormData and BlobBuilder - duplication of functionality?

[Jonas Sicking]

On Tue, Apr 13, 2010 at 5:34 PM, Michael Nordman  wrote:
> Hmmm... maybe FormData could have a toBlob() method, and an inverse means of
> initializing a FormData object with a properly encoded Blob.

What's the use case? ;)

/ Jonas

Re: FormData and BlobBuilder - duplication of functionality?

[Michael Nordman]

FormData produces multipart encoded data (with boundaries and such) whereas
BlobBuilder simply concatenates data together. Those are different
functions. Having different ctors for these object types
seems appropriate to me. There's also been talk of either initializing a
 with FormData and/or extracting FormData from a . If things
like that come to be, a different object type helps with clarity (at least
to me).

Hmmm... maybe FormData could have a toBlob() method, and an inverse means of
initializing a FormData object with a properly encoded Blob.

On Tue, Apr 13, 2010 at 5:11 PM, Dmitry Titov  wrote:

> Hi,
>
> It seems we are currently implementing 2 very similar objects - 
> FormData
>  and BlobBuilder.
> Both can be created, then strings or Blobs can be appended, then it can be
> sent via XHR or saved into a file (well, FormData can not be saved in the
> file yet). But, they are very similar:
>
> var bb = new BlobBuilder();
> bb.appendText("Lorem ipsum");
> bb.appendBlob(someBlob);
> xhr.send(bb.getBlob());
>
> var fd = new FormData();
> fd.appendText("data1", "Lorem ipsum");
> fd.appendBlob("data2", someBlob);
> xhr.send(fd);
>
> Are those two similar enough to justify merging them into a single object
> (defined as a a list of named BlobItems) that could be used for both?
>
> One difference is that BlobBuilder does not use a mime wrapper around data
> pieces, but rather concatenates them - there could be a property for that.
>
> Dmitry
>

FormData and BlobBuilder - duplication of functionality?

[Dmitry Titov]

Hi,

It seems we are currently implementing 2 very similar objects -
FormData
 and BlobBuilder .
Both can be created, then strings or Blobs can be appended, then it can be
sent via XHR or saved into a file (well, FormData can not be saved in the
file yet). But, they are very similar:

var bb = new BlobBuilder();
bb.appendText("Lorem ipsum");
bb.appendBlob(someBlob);
xhr.send(bb.getBlob());

var fd = new FormData();
fd.appendText("data1", "Lorem ipsum");
fd.appendBlob("data2", someBlob);
xhr.send(fd);

Are those two similar enough to justify merging them into a single object
(defined as a a list of named BlobItems) that could be used for both?

One difference is that BlobBuilder does not use a mime wrapper around data
pieces, but rather concatenates them - there could be a property for that.

Dmitry

Re: Not making partial result available during FileReader.readAsText()?

[Jian Li]

This is what I also feel. I am going to set total and loaded based on binary
data. Just want to make sure we're in the same page for those that are
spec-ed out clearly.

On Mon, Apr 12, 2010 at 5:31 PM, Jonas Sicking  wrote:

> Unfortunately I think decoded data is impossible as you have no idea
> what the total amount of decoded data will be until you've decoded the
> entire file.
>
> / Jonas
>
> On Mon, Apr 12, 2010 at 4:35 PM, Jian Li  wrote:
> > This sounds good. I have one more question related to this.
> > What are we going to set for total and loaded attributes for
> ProgressEvent?
> > Is it based on the decoded text or the underlying binary data?
> >
> >
> > On Fri, Apr 9, 2010 at 6:59 PM, Jonas Sicking  wrote:
> >>
> >> I think the spec should say MUST here, rather than SHOULD. Streaming
> >> contents seems as useful for text files as for binary files.
> >>
> >> The one thing that was tricky for us when implementing this was
> >> charset detection. We can't really expose any data until we've decided
> >> what charset to decode it with. However when loading normal pages over
> >> http the same situation arises, and all major browsers support
> >> streaming there.
> >>
> >> So I consider it a bug that firefox doesn't support this yet. It's
> >> something we should fix.
> >>
> >> / Jonas
> >>
> >> On Fri, Apr 9, 2010 at 6:33 PM, Jian Li  wrote:
> >> > Should we really want to support this? As I know, FF 3.6 does not
> >> > support
> >> > this in its current FileReader implementation. I just want to
> understand
> >> > if
> >> > there is a strong need for this.
> >> >
> >> > On Fri, Apr 9, 2010 at 5:49 PM, Michael Nordman 
> >> > wrote:
> >> >>
> >> >> Seems pretty clear from the snippet you provided, it says you SHOULD
> >> >> provide partially decoded results in the result attribute as progress
> >> >> is
> >> >> made.
> >> >>
> >> >> On Thu, Apr 8, 2010 at 8:31 PM, Jian Li  wrote:
> >> >>>
> >> >>> For FileReader.readAsText, the spec seems to allow partial file data
> >> >>> being decoded and saved in the result attribute when progress event
> is
> >> >>> fired:
> >> >>>
> >> >>> Make progress notifications. As the bytes from the fileBlob argument
> >> >>> are
> >> >>> read, user agents SHOULD ensure that on getting, the result
> attribute
> >> >>> returns partial file data representing the number of bytes currently
> >> >>> loaded
> >> >>> (as a fraction of the total) [ProgressEvents], decoded in memory
> >> >>> according
> >> >>> to the encoding determination.
> >> >>>
> >> >>> The partial file data read so far might not get decoded completely.
> >> >>> Could
> >> >>> we choose not to decode the partial result till we retrieve all the
> >> >>> data,
> >> >>> just like what FileReader.readAsDataURL does?
> >> >>
> >> >
> >> >
> >
> >
>

Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())

[Tyler Close]

On Tue, Apr 13, 2010 at 10:17 AM, Jonas Sicking  wrote:
> On Mon, Apr 12, 2010 at 5:28 PM, Jonas Sicking  wrote:
>> I wouldn't be opposed to implementing UMP, as long as there's a decent
>> API for invoking it, and that it's a good subset relative to CORS. I
>> think we've talked about various constructors or flags that let you
>> use the XHR API together with the UMP protocol.

I'm less concerned with the actual syntax, so please propose your
preferred choice. I just want something easy to use with the right
semantics.

> Oh, I should mention one concern that I have with UMP though. The spec
> seems to explicitly forbid sending the 'Referer' header [1]. I
> understand the purpose of this as the Referer header can be
> interpreted as ambient authentication.
>
> However a problem is that I think many sites rely on this header for
> things other than authentication. Such as measuring load from various
> 3rd parties, measuring who loads data in order to provide back links,
> etc. This is done for public data as much as for private.
>
> I don't have a solution to propose. Nor do I at this time think that
> this is a blocker issue. However I wouldn't be surprised if sites will
> not want to deploy UMP because of this.

There are a number of click tracking techniques that use unique URLs,
instead of the Referer header. In many cases, these techniques are
more reliable since some firewalls drop the Referer header and caching
proxies can prevent requests from reaching the hosting server at all.
I'm hopeful these techniques will support traffic analysis of public
data offered via UMP, without the security hazards created by the
Referer header.

> [1] Section 3.2, Sending a Uniform Request, says: "MUST NOT add any
> information obtained from ... or the referring resource". For what
> it's worth, I think this could be made more clear.

Thanks, I'll attempt a different phrasing.

Thanks for the feedback.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Re: XMLHttpRequest Priority Proposal

[Mike Belshe]

On Tue, Apr 13, 2010 at 9:36 AM, Olli Pettay wrote:

> Hi,
>
>
Thanks for the comments.



> this seems like a pretty useful, yet reasonable easily implementable
> feature.
>

Good to hear.


> I'd add 5th value "NORMAL", which would be the default value.
>
>   const unsigned short CRITICAL = 0;
>   const unsigned short HIGH = 1;
>   const unsigned short NORMAL = 2
>   const unsigned short LOW = 3;
>   const unsigned short LOWEST = 4;
>
> Not sure if we need all the values, or would
> HIGH, NORMAL, LOW be enough?
>


 I'm not fussy about what priorities are exposed or what we call them - so
long as they are relatively few in number to avoid unnecessary complexity.
 (e.g. 3-5 priority buckets seems fine)

Mike


>
>
> -Olli
>
>
>
> On 4/13/10 7:13 PM, Mike Belshe wrote:
>
>> Hi,
>>
>> I'm a developer on the chrome team, and also working on SPDY.
>>
>> Others here at Google have requested that we expose some of the
>> priority-based resource loading mechanics to applications so that
>> applications can hint to the browser more information about which
>> resources are critical and which are not.  Some of the Google Apps teams
>> have already implemented their own, manual priority-based resource
>> fetchers, and our maps team saw a huge latency reduction as a result of
>> doing so.  Internally to chromium and webkit, resource loading is also
>> priority-aware today.  Finally, in SPDY, we've observed good
>> improvements by exposing priorities all the way across the protocol.  We
>> believe exposing priority on the XHR object may benefit many
>> applications manage their resource loads.
>>
>> Here is a quick writeup of one proposal which we think would work in
>> browsers.  We believe it is backward compatible with existing XHR, and
>> can be optionally implemented.  It also leaves a fair amount of the
>> tuning at the discretion of the browser, so it does not create a
>> long-term liability in the browser.  We hope that these considerations
>> make it an easy choice to approve.
>>
>> I'm wondering if the XMLHttpRequest group would be interested in taking
>> this on?
>>
>> Thanks,
>> Mike
>>
>>
>>  XMLHttpRequest Priority Fetching
>>
>> Every performant web browser implementation today implements various
>> heuristics for resource loading prioritization internally.  The notion
>> is simple, that loading some resources, such as images, are less
>> performance critical than loading other resources, such as external
>> style sheets.  By implementing basic priorities, browsers achieve
>> substantially better performance loading web pages.  Today, however, web
>> applications have no way of giving hints to the browser about what may
>> be high or low priority.
>>
>> Because complex applications heavily rely on resource loading by way of
>> XmlHttpRequest, we propose a simple, backward compatible, and optional
>> mechanism whereby application developers can hint to a browser how to
>> load a XmlHttpRequest.
>>
>> Proposed API:
>> interface XMLHttpRequest {
>>  // XMLHttpRequest Priorities.
>>  const unsigned short CRITICAL = 0;
>>  const unsigned short HIGH = 1;
>>  const unsigned short LOW = 2;
>>  const unsigned short LOWEST = 3;
>>
>>  // Set the load priority for this request.
>>  void setPriority(unsigned short priority);
>> }
>>
>>
>>
>> Example Usage:
>> var client = new XMLHttprequest;
>> client.setPriority(HIGH);
>> client.open(’GET’, ‘demo.cgi’);
>> client.send();
>>
>>
>>
>> Description:
>> When a new XMLHttpRequest object is created, it contains a notion of
>> priority.  Browsers which schedule resource fetches may optionally use
>> this priority to determine in which order resources are fetched.
>>
>> 4 priorities are provided.  By keeping the number of different
>> priorities small, we keep browser and XMLHttpRequest priority
>> implementations simple.
>>
>> By default, all XMLHttpRequest objects have a priority ‘LOW’.
>>
>> Applications may alter the priority by calling the setPriority() method
>> on the XMLHttpRequest object.  The priority set on the object at the
>> time the applicaiton calls the XMLHttpRequest.send() method determines
>> the priority the browser should use when fetching this resource.
>>  Calling setPriority() after the send() method will have no effect on
>> the priority of the resource load.
>>
>> Browsers are not required to support the priority requested by
>> applications, and may ignore it altogether.  However, browsers are
>> encouraged to support the requested priority order.  The following is a
>> description of one possible prioritization policy:
>>   CRITICAL resources are loaded first.  When CRITICAL resources are in
>> progress, requests for HIGH/MEDIUM/LOW resources are deferred until all
>> CRITICAL resources have finished.
>>   HIGH/MEDIUM/LOW resources are loaded in that order.  When no CRITICAL
>> resources are in progress, HIGH/MEDIUM/LOW resources will be loaded with
>> HIGH priority first.  The browser does not need to wait until higher
>> priority resources hav

Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())

[Jonas Sicking]

On Mon, Apr 12, 2010 at 5:28 PM, Jonas Sicking  wrote:
> On Mon, Apr 12, 2010 at 4:28 PM, Tyler Close  wrote:
>> On Mon, Apr 12, 2010 at 4:14 PM, Jonas Sicking  wrote:
>>> On Mon, Apr 12, 2010 at 3:48 PM, Tyler Close  wrote:
 On Mon, Apr 12, 2010 at 3:41 PM, Jonas Sicking  wrote:
> On Mon, Apr 12, 2010 at 3:10 PM, Tyler Close  
> wrote:
>>> I think even taken together, your set of subset conditions does 
>>> guarantee
>>> that a CORS client implementation is automatically also a UMP client
>>> implementation. If we went that way, then we would have to consider 
>>> whether
>>> there will ever be client implementors of UMP itself, or it will be
>>> impossible to fulfill CR exit criteria.
>>
>> If there are implementers of CORS, then by definition, there are
>> implementers of UMP. I don't see anything in CR exit criteria that
>> requires implementers to swear not to also implement other
>> specifications.
>
> So is sending the 'Origin' and 'Referer' headers ok per UMP?

 Sending "Origin: null" is OK per UMP. Similarly, an "null"-like value
 for Referer would be OK.

> The current CORS implementation in firefox always sends those headers.

 Then that implementation is only compatible with UMP when used in
 combination with some mechanism for putting the requesting content in
 an anonymous . Ideally, Firefox would allow this to be
 expressed via the messaging API instead of requiring the anonymous
 .

> I would have imagined that UMP would explicitly forbid any ambient
> authority or identity information other than IP number?

 Correct.
>>>
>>> It seems to me then that Firefox implements CORS, but does not
>>> implement UMP. The fact that a web page can use javascript to
>>> implement UMP using the primitives implemented by the browser doesn't
>>> change the fact that the browser doesn't implement UMP. We have had
>>> similar situations in the past where javascript libraries have been
>>> able to implement various CSS features, despite those features not
>>> being natively implemented by the browser. I also think it would be
>>> possible to implement CORS purely in javascript as well, as long as
>>> you can set the 'Origin' header for same-site XHR requests (this is
>>> possible in older browser versions).
>>>
>>> We have traditionally not counted such javascript implementations
>>> towards the "two implementations" requirement.
>>
>> Does that tradition necessarily apply to a specification that only
>> defines a security policy and no API, such as CORS or UMP? That kind
>> of spec hasn't been done before. With the CSS example, there is an
>> actual piece of syntax you can point to and show that the browser
>> doesn't implement it. In UMP, the only syntax to point at is the
>> "Access-Control-Allow-Origin" header and Firefox implements that as
>> specified. Neither CORS nor UMP specify the syntax required for making
>> a request. The browser is free to use whatever arcane syntax it wants.
>
> Yes, both CORS and UMP are effectively protocol specifications. Other
> specs, such as XHR L2, specifies when they are to be used. I don't
> think that makes a difference as far as the 2 implementation
> requirement though. But note that I'm not the ultimate authority on
> the matter by any means.
>
>> In either case, my ultimate goal is to get a nice syntax for UMP in
>> the browser. Given that we all recognize the value of this
>> functionality and some have actually implemented it, why not give it a
>> nice syntax? Shouldn't a future version of Firefox make it easy to
>> express a uniform request instead of requiring the developer to jump
>> through hoops?
>
> I wouldn't be opposed to implementing UMP, as long as there's a decent
> API for invoking it, and that it's a good subset relative to CORS. I
> think we've talked about various constructors or flags that let you
> use the XHR API together with the UMP protocol.

Oh, I should mention one concern that I have with UMP though. The spec
seems to explicitly forbid sending the 'Referer' header [1]. I
understand the purpose of this as the Referer header can be
interpreted as ambient authentication.

However a problem is that I think many sites rely on this header for
things other than authentication. Such as measuring load from various
3rd parties, measuring who loads data in order to provide back links,
etc. This is done for public data as much as for private.

I don't have a solution to propose. Nor do I at this time think that
this is a blocker issue. However I wouldn't be surprised if sites will
not want to deploy UMP because of this.

[1] Section 3.2, Sending a Uniform Request, says: "MUST NOT add any
information obtained from ... or the referring resource". For what
it's worth, I think this could be made more clear.

/ Jonas

Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())

[Arthur Barstow]

On Apr 12, 2010, at 4:00 PM, ext Maciej Stachowiak wrote:


On Apr 12, 2010, at 10:33 AM, Tyler Close wrote:


I've added a new section to the wiki page, "UMP as subset of CORS":

http://www.w3.org/Security/wiki/ 
Comparison_of_CORS_and_UMP#UMP_as_subset_of_CORS




I do not think the set of subset criteria posted there matches what I
proposed and what we've been discussing in this thread. Should I put
some abbreviated form of my proposal in the wiki?


I think that would be useful since you've now stated a subset of your  
original properties would be sufficient.



I am not sure what
the conventions are for editing this wiki page.


AFAIK, no specific conventions were set for that page so anyone in  
the group should feel to modify it (I believe Thomas created the  
Security page so he indicate otherwise).


-Art Barstow

Re: XMLHttpRequest Priority Proposal

[Olli Pettay]

Hi,

this seems like a pretty useful, yet reasonable easily implementable
feature.
I'd add 5th value "NORMAL", which would be the default value.
   const unsigned short CRITICAL = 0;
   const unsigned short HIGH = 1;
   const unsigned short NORMAL = 2
   const unsigned short LOW = 3;
   const unsigned short LOWEST = 4;

Not sure if we need all the values, or would
HIGH, NORMAL, LOW be enough?


-Olli


On 4/13/10 7:13 PM, Mike Belshe wrote:

Hi,

I'm a developer on the chrome team, and also working on SPDY.

Others here at Google have requested that we expose some of the
priority-based resource loading mechanics to applications so that
applications can hint to the browser more information about which
resources are critical and which are not.  Some of the Google Apps teams
have already implemented their own, manual priority-based resource
fetchers, and our maps team saw a huge latency reduction as a result of
doing so.  Internally to chromium and webkit, resource loading is also
priority-aware today.  Finally, in SPDY, we've observed good
improvements by exposing priorities all the way across the protocol.  We
believe exposing priority on the XHR object may benefit many
applications manage their resource loads.

Here is a quick writeup of one proposal which we think would work in
browsers.  We believe it is backward compatible with existing XHR, and
can be optionally implemented.  It also leaves a fair amount of the
tuning at the discretion of the browser, so it does not create a
long-term liability in the browser.  We hope that these considerations
make it an easy choice to approve.

I'm wondering if the XMLHttpRequest group would be interested in taking
this on?

Thanks,
Mike


  XMLHttpRequest Priority Fetching

Every performant web browser implementation today implements various
heuristics for resource loading prioritization internally.  The notion
is simple, that loading some resources, such as images, are less
performance critical than loading other resources, such as external
style sheets.  By implementing basic priorities, browsers achieve
substantially better performance loading web pages.  Today, however, web
applications have no way of giving hints to the browser about what may
be high or low priority.

Because complex applications heavily rely on resource loading by way of
XmlHttpRequest, we propose a simple, backward compatible, and optional
mechanism whereby application developers can hint to a browser how to
load a XmlHttpRequest.

Proposed API:
interface XMLHttpRequest {
  // XMLHttpRequest Priorities.
  const unsigned short CRITICAL = 0;
  const unsigned short HIGH = 1;
  const unsigned short LOW = 2;
  const unsigned short LOWEST = 3;

  // Set the load priority for this request.
  void setPriority(unsigned short priority);
}



Example Usage:
var client = new XMLHttprequest;
client.setPriority(HIGH);
client.open(’GET’, ‘demo.cgi’);
client.send();



Description:
When a new XMLHttpRequest object is created, it contains a notion of
priority.  Browsers which schedule resource fetches may optionally use
this priority to determine in which order resources are fetched.

4 priorities are provided.  By keeping the number of different
priorities small, we keep browser and XMLHttpRequest priority
implementations simple.

By default, all XMLHttpRequest objects have a priority ‘LOW’.

Applications may alter the priority by calling the setPriority() method
on the XMLHttpRequest object.  The priority set on the object at the
time the applicaiton calls the XMLHttpRequest.send() method determines
the priority the browser should use when fetching this resource.
  Calling setPriority() after the send() method will have no effect on
the priority of the resource load.

Browsers are not required to support the priority requested by
applications, and may ignore it altogether.  However, browsers are
encouraged to support the requested priority order.  The following is a
description of one possible prioritization policy:
   CRITICAL resources are loaded first.  When CRITICAL resources are in
progress, requests for HIGH/MEDIUM/LOW resources are deferred until all
CRITICAL resources have finished.
   HIGH/MEDIUM/LOW resources are loaded in that order.  When no CRITICAL
resources are in progress, HIGH/MEDIUM/LOW resources will be loaded with
HIGH priority first.  The browser does not need to wait until higher
priority resources have finished fetching before it starts a request for
a lower priority resource, although it may chose to do so.

Existing Implementations:
Google is currently using resource prioritization techniques in its
Google Maps application, internally to the Google Chrome browser, and
also as a part of the SPDY protocol.

XMLHttpRequest Priority Proposal

[Mike Belshe]

Hi,

I'm a developer on the chrome team, and also working on SPDY.

Others here at Google have requested that we expose some of the
priority-based resource loading mechanics to applications so that
applications can hint to the browser more information about which resources
are critical and which are not.  Some of the Google Apps teams have already
implemented their own, manual priority-based resource fetchers, and our maps
team saw a huge latency reduction as a result of doing so.  Internally to
chromium and webkit, resource loading is also priority-aware today.
 Finally, in SPDY, we've observed good improvements by exposing priorities
all the way across the protocol.  We believe exposing priority on the XHR
object may benefit many applications manage their resource loads.

Here is a quick writeup of one proposal which we think would work in
browsers.  We believe it is backward compatible with existing XHR, and can
be optionally implemented.  It also leaves a fair amount of the tuning at
the discretion of the browser, so it does not create a long-term liability
in the browser.  We hope that these considerations make it an easy choice to
approve.

I'm wondering if the XMLHttpRequest group would be interested in taking this
on?

Thanks,
Mike


XMLHttpRequest Priority FetchingEvery performant web browser implementation
today implements various heuristics for resource loading prioritization
internally.  The notion is simple, that loading some resources, such as
images, are less performance critical than loading other resources, such as
external style sheets.  By implementing basic priorities, browsers achieve
substantially better performance loading web pages.  Today, however, web
applications have no way of giving hints to the browser about what may be
high or low priority.

Because complex applications heavily rely on resource loading by way of
XmlHttpRequest, we propose a simple, backward compatible, and optional
mechanism whereby application developers can hint to a browser how to load a
XmlHttpRequest.

Proposed API:
interface XMLHttpRequest {
 // XMLHttpRequest Priorities.
 const unsigned short CRITICAL = 0;
 const unsigned short HIGH = 1;
 const unsigned short LOW = 2;
 const unsigned short LOWEST = 3;

 // Set the load priority for this request.
 void setPriority(unsigned short priority);
}

Example Usage:
var client = new XMLHttprequest;
client.setPriority(HIGH);
client.open(’GET’, ‘demo.cgi’);
client.send();

Description:
When a new XMLHttpRequest object is created, it contains a notion of
priority.  Browsers which schedule resource fetches may optionally use this
priority to determine in which order resources are fetched.

4 priorities are provided.  By keeping the number of different priorities
small, we keep browser and XMLHttpRequest priority implementations simple.

By default, all XMLHttpRequest objects have a priority ‘LOW’.

Applications may alter the priority by calling the setPriority() method on
the XMLHttpRequest object.  The priority set on the object at the time the
applicaiton calls the XMLHttpRequest.send() method determines the priority
the browser should use when fetching this resource.  Calling setPriority()
after the send() method will have no effect on the priority of the resource
load.

Browsers are not required to support the priority requested by applications,
and may ignore it altogether.  However, browsers are encouraged to support
the requested priority order.  The following is a description of one
possible prioritization policy:
  CRITICAL resources are loaded first.  When CRITICAL resources are in
progress, requests for HIGH/MEDIUM/LOW resources are deferred until all
CRITICAL resources have finished.
  HIGH/MEDIUM/LOW resources are loaded in that order.  When no CRITICAL
resources are in progress, HIGH/MEDIUM/LOW resources will be loaded with
HIGH priority first.  The browser does not need to wait until higher
priority resources have finished fetching before it starts a request for a
lower priority resource, although it may chose to do so.

Existing Implementations:
Google is currently using resource prioritization techniques in its Google
Maps application, internally to the Google Chrome browser, and also as a
part of the SPDY protocol.

Re: [IndexedDB] Granting storage quotas

[João Eiras]

On Tue, 13 Apr 2010 12:09:14 +0200, Mark Seaborn   
wrote:


Is there any plan for involving the user in storage allocation decisions  
for

IndexedDB? [1]

For comparison, the WebStorage API [2] doesn't have any special support  
for
the user to make allocation choices.  My understanding is that browsers  
have

a fixed storage limit per origin -- in Chromium, 5Mb per origin.  The
problem with this model is that it is both too permissive and too
restrictive.


Not really. The user agent can ask for quota from the user when the limit  
is being hit without the webpage even having to worry about it. Opera  
10.50 does that.

Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())

[Anne van Kesteren]

On Tue, 13 Apr 2010 02:28:53 +0200, Jonas Sicking  wrote:

I wouldn't be opposed to implementing UMP, as long as there's a decent
API for invoking it, and that it's a good subset relative to CORS. I
think we've talked about various constructors or flags that let you
use the XHR API together with the UMP protocol.


XMLHttpRequest Level 2 defines a constructor for XMLHttpRequest that  
enforces certain properties of CORS. That gives you something that looks  
like UMP, but you don't need UMP for it. You just need to implement CORS  
and XMLHttpRequest Level 2. (It may be certain aspects need further  
clarification/fixing, but that seems somewhat unrelated of what would be  
the preferred approach.)



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

Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())

[Anne van Kesteren]

On Mon, 12 Apr 2010 15:49:22 +0200, Arthur Barstow   
wrote:
Anne - as Maciej mentioned in another thread [2], it would be good to  
get your feedback on this subject.


I don't really care about subset relations to be honest. Fixing bugs in  
CORS is fine, and I think that is what we should be focusing on, rather  
than trying to go along with several drafts that may or may not be subsets.




[1] http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP
[2]  
http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0058.html



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

Re: Extending CSSOM Views matchMedium with callback

[Anne van Kesteren]

On Tue, 13 Apr 2010 15:39:47 +0200, Arthur Barstow   
wrote:
All - FYI, I think the next steps here are to hash out some process  
related issues so I started a related discussion on the public- 
hypertext-cg mail list:


   http://lists.w3.org/Archives/Public/public-hypertext-cg/2010AprJun/0001.html


I think more use case examples would still be good, but as I already  
indicated on IRC adding a callback to matchMedium that is invoked the  
moment the evaluation of the media query changes with respect to the  
current rendering view is not a big deal and certainly should not require  
charter discussion or a task force. The mailing list for CSSOM View is  
www-style and I don't really see a reason to change that either.



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

Re: Extending CSSOM Views matchMedium with callback Re: CSS WG comments on View Modes Media Feature spec

[Arthur Barstow]

All - FYI, I think the next steps here are to hash out some process  
related issues so I started a related discussion on the public- 
hypertext-cg mail list:


  http://lists.w3.org/Archives/Public/public-hypertext-cg/2010AprJun/ 
0001.html


-Art Barstow


On Apr 12, 2010, at 4:12 PM, ext Marcos Caceres wrote:



On Apr 12, 2010, at 8:50 PM, Simon Fraser  wrote:



On Apr 12, 2010, at 2:25 AM, Marcos Caceres wrote:


On Fri, Mar 26, 2010 at 2:25 PM, Marcos Caceres 
wrote:

On Thu, Mar 18, 2010 at 4:02 PM, Simon Fraser  wrote:

On Mar 18, 2010, at 6:44 AM, Marcos Caceres wrote:


4. all these queries could/should have an event-based
counterpart so the
 changes are detectable by code. We understand this is outside
of the
 scope of this spec but that's still an important comment.


We have a proposal already for the CSS WG to review:
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html


It seems like this needs to align to the current CSS OM View spec:


which has a StyleMedia interface available on the window object
as 'styleMedia', rather than 'media'.

I would expect to see events related to media type changes in the
CSS OM View spec too, rather than in a widgets-related spec.


I totally agree, there is much overlap. We should start looking at
how
to merge the two specs (or our requirements) into the CSS OM View
spec. I would be happy for the widgets one to vanish if the CSS OM
View spec would handled our use cases.

Perhaps we should have a joint teleconf or something to arrange
how to
proceed...  I'll leave that up to the chairs, however.


To make Widget View Modes Interfaces [1] redundant, we would like to
propose extending CSSOM Views' matchMedium method to have a callback
as a second argument.

This would address the following sections of [1] in the following
ways:

# 3.2. Media Type Changed Event Types
styleMedia.matchMedium("screen", function() { alert("no
longer screen!") })

# 3.3. View Mode Changed Event Types
styleMedia.matchMedium("(viewmodesyntax)", ... )

# 3.4. Resolution Changed Event Types
styleMedia.matchMedium("(resolution:300dpi)", ... )

# 3.5. Orientation Changed Event Types
styleMedia.matchMedium("(orientation:landscape)", ... )

The proposal has it's origins on the Mozilla bug list (see comment
from David Baron):
https://bugzilla.mozilla.org/show_bug.cgi?id=542058#c3


This is overlapping with ViewModeChanged events:

Re: VMMF updated

[Arthur Barstow]

Robin, All,

On Apr 12, 2010, at 7:15 AM, ext Robin Berjon wrote:

VMMF has been updated with all feedback that had been sent to the  
list, I look forward to commenters indicating love or hatred for  
the changes.


I support the recent changes and think the spec is ready for LC.


There are two things that I've left unaddressed for the WG to decide:

  - Changing the shortname to something not widget-related: css3- 
vmmf? vmmf? vm-media?


"vmmf" is OK as is view-mode.


  - Do we have a "hidden" value? If so, is it "at risk"?


I haven't seen strong indications it must be added and as you  
indicated earlier [1], it could be added later.


-Art Barstow

[1] http://www.w3.org/mid/B08BB4AE- 
dc83-4238-8d2e-37a44b015...@berjon.com

[IndexedDB] Granting storage quotas

[Mark Seaborn]

Is there any plan for involving the user in storage allocation decisions for
IndexedDB? [1]

For comparison, the WebStorage API [2] doesn't have any special support for
the user to make allocation choices.  My understanding is that browsers have
a fixed storage limit per origin -- in Chromium, 5Mb per origin.  The
problem with this model is that it is both too permissive and too
restrictive.

 1) It is too restrictive because a user might want to grant a web app a
large quantity of storage -- perhaps gigabytes.  (See use cases below.)

 2) It is too permissive because it enforces no limit on the amount of space
a web app can use:  A web app from example.com can create an unlimited
number of puppet subdomains:  aaa.example.com, bbb.example.com, etc.  It can
use aaa.example.com's 5Mb allocation by loading a script from
aaa.example.com in an iframe and communicating with it using postMessage().

Both WebStorage and and IndexedDB have sections titled "Blocking third-party
storage" which permit browsers to disallow access to local storage from
iframes.  This could *potentially* address (2), although the specs frame
this as a privacy issue rather than a resource allocation issue.  However,
if browsers opted to block local storage access in iframes, this would
reduce composability of web apps, because WebStorage/IndexedDB provide no
other way for one site to delegate access to its storage to another site.
Furthermore, leaving this unspecified dilutes the value of having a spec,
because there would be no behaviour that all web apps can depend on.


My proposal:

Add a requestQuota() interface to IndexedDB that allows a web app to ask for
an amount of storage.

The form of the request affects how it can be displayed to the user:

 * Suppose this is a Javascript method call, e.g.
  indexedDB.requestQuota(size_in_megabytes)
   The request could be displayed as an info bar, which would be
   displayed asynchronously, i.e. without the user clicking.

 * Alternatively, the request could be attached to a DOM element
   (e.g. an  element), which would be displayed as a button.
   Clicking the button opens a dialog.

The dialog would display the amount of storage that the web app has
requested.  The user can change the amount of storage, or grant the request
without change.  The dialog might also display how much storage is currently
available on the user's device.

A site's quota would be zero by default, otherwise a web app can multiply
any non-zero limit by the number of domains is can invent, as described
above.

A quota would be an upper limit on the space a site can use, but it would
not be a guarantee that the space is available.


Use cases:

* An e-mail web app requests an amount of storage that is large enough to
store all your current e-mail, plus your e-mail for the next year at
projected rates.  As this runs out, it can request more.

* A backup web app requests an amount that is large enough to store your
data.

Mark

[1] http://www.w3.org/TR/IndexedDB/
[2] http://dev.w3.org/html5/webstorage/

Re: Server Sent Events vs Web Sockets?

[Dominique Hazael-Massieux]

Le lundi 12 avril 2010 à 17:47 +, Ian Hickson a écrit :
> Server sent events doesn't require any change to the network, it's 
> compatible with almost any setup that uses HTTP today. Web Sockets 
> requires that intermediaries support full-duplex connections. Server sent 
> events is compatible with today's HTTP servers. Web Sockets requires new 
> Web Socket servers.

OK — in other words, Server Sent Events should be easier to deploy.

>  Server Sent Events has a variety of features that Web 
> Sockets lacks by design, such as reconnection, event IDs, and the ability 
> to send arbitrary events.

So, Server Sent Events adds to Web Sockets a specific protocol for
dealing with events, a useful pattern to optimize. 

> These differences mean that there will likely be a reason for both to 
> exist for a long time.

Yeah, I didn't mean to question that; I'm just trying to see the full
picture.

> > Currently, the two documents don't reference each other at all; some 
> > clarification of their relationship in the specs themselves would be 
> > useful, I think.
> 
> They're part of the same document:
>http://www.whatwg.org/specs/web-apps/current-work/complete.html#comms

Whether you consider them as sections or documents, I think it would
still be useful to document (however briefly) their interrelationship
(as you just did).

Thanks!

Dom