Re: [whatwg] WebSockets: what to do when there are too many open connections
On Wed, 12 May 2010 20:01:11 +0200, Ojan Vafai o...@chromium.org wrote: On Wed, May 12, 2010 at 4:31 AM, Simon Pieters sim...@opera.com wrote: establishing a WebSocket connection: [[ Note: There is no limit to the number of established WebSocket connections a user agent can have with a single remote host. Servers can refuse to connect users with an excessive number of connections, or disconnect resource-hogging users when suffering high load. ]] Still, it seems likely that user agents will want to have limits on the number of established WebSocket connections, whether to a single remote host or multiple remote hosts, in a single tab or overall. Why? Is the concern that we'd run out of memory? Overload the user's network connection? If nothing else, the underlying OS might have a limit on the number of open connections. -- Simon Pieters Opera Software
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Wed, 12 May 2010 20:51:59 +0200, Michael Nordman micha...@google.com wrote: On Wed, May 12, 2010 at 4:31 AM, Simon Pieters sim...@opera.com wrote: establishing a WebSocket connection: [[ Note: There is no limit to the number of established WebSocket connections a user agent can have with a single remote host. Servers can refuse to connect users with an excessive number of connections, or disconnect resource-hogging users when suffering high load. ]] Still, it seems likely that user agents will want to have limits on the number of established WebSocket connections, whether to a single remote host or multiple remote hosts, in a single tab or overall. The question is what should be done when the user agent-defined limit of established connections has been reached and a page tries to open another WebSocket. I think just waiting for other WebSockets to close is not good. It just means that newly loaded pages don't work. Agreed, not good. The intent of the api is to start opening a socket now, not at some undefined point in the future after the user has taken some undefined action (hey user... please close a tab that has a socket open... not particularly user actionable). If there are any WebSockets in CLOSING state, then I think we should wait until they have closed. Otherwise, I think we should force close the oldest WebSocket. Force closing the oldest is not good. A malicious site could cause all open sockets to be closed. Also this would have nasty side effects. Consider a memory allocator that just deleted the oldest allocation to make room for new allocations, far removed things just start failing on odd ways... no thank you. An obvious way to handle this condition of too many sockets are open is to fail to open the new socket with an exception/error which indicates that condition. But then to make the page work the user still has to close a tab that has a socket open. But maybe just firing a 'close' event and logging in the error console is the best thing to do. -- Simon Pieters Opera Software
Re: [whatwg] Image resize API proposal
Am 11.05.2010 20:58 schrieb Sterling Swigart:
I'm working with David Levin, and based on the feedback received
regarding offscreen canvas, the proposal has been changed to address
more specific scenarios. The main use case was resizing images, so we
are proposing an asynchronous image resizing API. If you are curious
about how we arrived at our API below, take a look at the appendix to
view the alternatives we considered.
Let us know what you think. Thanks!
Sterling
Use Cases:
Begin with a user giving a local image file to a webpage. Then:
1. In real-time chat, quickly give other users a thumbnail view of the
image file.
2. Or, limit the size of an image file before uploading it to a web server.
Proposed Solution:
We propose adding image.getBlob. getBlob will be an instance function of
the javascript Image object which asynchronously gets a blob of the
image, resized to the given width and height, encoded into jpeg or png.
The function declaration will be:
getBlob(mimeType /* req */, width /* req */, height /* req */,
successEvent /* req */, errorEvent /* op */, qualityLevel /* op */,
preserveAspectRatio /* op */, rotateExif /* op */);
I am a web author with limited scripting knowledge, so I apologize I
can't give a qualified feedback to your proposal in detail.
Generally I consider client side image resizing a very good idea;
currently I use a Java applet for this purpose, and of course it would
be nice to have this functionality natively in browsers. Anyway, for
submitting the image in a form (which both your use cases are about), I
would not primarily expect a function that returns a blob, but rather
one that modifies the image data. E.g.:
function resize(mimeType, width, height, keepAspectRatio, qualityLevel)
For the image upload use case, calling the function via event-handler in
the file input control affects the image data in the form data:
input type=file onSubmit=resize('image/jpeg', 300, 350, true)
I do not understand what use cases could be other than modifying images
for form upload, but if there are any, the same method could be applied
to the image object (given that the method waits for the image data to
be completely loaded):
var i = document.getElementById(myImg);
i.resize('image/png', 300, 350, true, .95);
This would have mainly the same effect as changing i.style.width and
i.style.height, except you can specify the quality level. (Maybe the
argument order should be changed the way that the mime type can be
optional, as in this case most authors would not really care about the
mime type - except that it might be nice to convert a gif with
transparency into a png to get the transparency edges antialiased.)
If you need the blob data for further processing, a separate getBlob()
function would be needed.
var i = new Image();
i.src = my/img/url.jpg;
i.resize('image/jpeg', 300, 350, true, .55);
var blobData = i.getBlob();
Re: [whatwg] WebSockets: what to do when there are too many open connections
On May 13, 2010, at 10:05 AM, Simon Pieters wrote: On Wed, 12 May 2010 20:51:59 +0200, Michael Nordman micha...@google.com wrote: On Wed, May 12, 2010 at 4:31 AM, Simon Pieters sim...@opera.com wrote: establishing a WebSocket connection: [[ Note: There is no limit to the number of established WebSocket connections a user agent can have with a single remote host. Servers can refuse to connect users with an excessive number of connections, or disconnect resource-hogging users when suffering high load. ]] Still, it seems likely that user agents will want to have limits on the number of established WebSocket connections, whether to a single remote host or multiple remote hosts, in a single tab or overall. The question is what should be done when the user agent-defined limit of established connections has been reached and a page tries to open another WebSocket. I think just waiting for other WebSockets to close is not good. It just means that newly loaded pages don't work. Hosts have limits on open file descriptors but they are usually in the ten's of thousands (per process) on today's OSs. I don't think this is an area for the spec. The open must be allowed to fail if something goes wrong. The OS might reject it and the browser might reject it too. Aside from that, I don't think the spec should dictate what to do here. A nice UA, I think, would monitor a particular tab or browsing context for being out of control. This might be opening an infinite number of sockets or running infinite threads to bog the user's system down (or it might be because I forgot a semicolon :-). There are countless ways for nasty javascript to upset the user. A nice UA from a nice group would learn these new ways and adapt to them over time. When detected, the UA could ask the user if they want this mayhem to continue or not. I think rampant socket abuse is just one of countless places nasty javascript is going to exploit the user. I don't see how the spec can foresee all of them nor should a complaint UA be required to detect all of them. Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 13, 2010 at 1:19 PM, Perry Smith pedz...@gmail.com wrote: [[ Note: There is no limit to the number of established WebSocket connections a user agent can have with a single remote host. Servers can refuse to connect users with an excessive number of connections, or disconnect resource-hogging users when suffering high load. ]] I don't think this is an area for the spec. The open must be allowed to fail if something goes wrong. The OS might reject it and the browser might reject it too. Aside from that, I don't think the spec should dictate what to do here. A nice UA, I think, would monitor a particular tab or browsing context for being out of control. This might be opening an infinite number of sockets or running infinite threads to bog the user's system down (or it might be because I forgot a semicolon :-). There are countless ways for nasty javascript to upset the user. A nice UA from a nice group would learn these new ways and adapt to them over time. When detected, the UA could ask the user if they want this mayhem to continue or not. I think rampant socket abuse is just one of countless places nasty javascript is going to exploit the user. I don't see how the spec can foresee all of them nor should a complaint UA be required to detect all of them. I think simply saying that a user agent may restrict the number of connections like the server might is sufficient. As written, it implies the number is actually unlimited. -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 13, 2010 at 1:19 PM, Perry Smith pedz...@gmail.com wrote: Hosts have limits on open file descriptors but they are usually in the ten's of thousands (per process) on today's OSs. I have to admit, I'd be a little surprised (I think pleasantly, but maybe not) if I could open ten thousand file descriptors on the latest shipping Windows CE, or for that matter on an iPhone. The question is whether you queue or give an error. When hitting the RFC-ish per-host connection limits, browsers queue additional requests from img or such, rather than erroring them out. Not sure that's the right model here, but I worry about how much boilerplate code there will need to be to retry the connection (asynchronously) to handle failures, and whether people will end up writing it or just hoping for the best. Mike
Re: [whatwg] Changing punctuation value of input element in telephone state
On 04/07/2010 03:49 AM, Mikko Rantalainen wrote: And nowadays you will see stuff like this: +358 (012) 1234 567 This contains the area code for Finland +358 in addition to the Finnish local distance number. However, there's a catch! When dialing, you must press +358121234567 because the first zero of area code is dropped if there's a country code. As a result, it's not safe to blindly drop the parenthesis from user inputted phone number. This is the case in the UK too. While in the US phone users tend to realise that the 1 on the front of the number is the national dialling prefix, in the UK the 0 that signals national dialling is always quoted as part of the dialling code, and phone users who don't use international numbers frequently don't realize that it's not strictly part of the telephone number. A common notation for UK numbers with an international prefix is: +44 (0)1206 123456 ...which, just as in your Finnish example, is either dialled as +441206123456 or as 01206123456 (were + stands in for your country's international dialling prefix.). Dialling +4401206123456 doesn't work. So with all that said, I don't think dropping punctuation is an adequate solution. Cellphones I've had both the US and the UK seem to be able to recognize the local conventions and normalize them to the correct form for number recognition, so perhaps browsers could adopt the same appraoch but this assumes that they would be able to detect what geographical area they are being used in and have support for various international numbering schemes, which seems like a big burden to put on a browser when dealing with telephone numbers is not its core concern.
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 13, 2010 at 1:40 PM, Mike Shaver mike.sha...@gmail.com wrote: I have to admit, I'd be a little surprised (I think pleasantly, but maybe not) if I could open ten thousand file descriptors on the latest shipping Windows CE, or for that matter on an iPhone. ulimit -n tells me I can only open 1024 per process on my desktop and server Linux machines. Actually, I had to configure lighttpd on my server to raise its max file descriptors to 4096 to make sure it could handle all my keepalive connections (although maybe it could have anyway).
Re: [whatwg] Image resize API proposal
This really seems like the wrong solution. Taken to an extreme next you'll
need to add VideoRisizer, AudioRecompresser, and any thing else JavaScript
can't do without freezing the browser.
It seems like it would be better to figure out a way to get Web Workers to
be able to do this. Even if they have to XHR the binary down, decompress
into a TypeArray (see WebGL) and read the data themsevles so they can keep
the EXIF stuff, bloating the browser for one small use doesn't seem like the
right solution.
You can post an open source library and the usage can be as simple as this
proposal.
On Tue, May 11, 2010 at 11:58 AM, Sterling Swigart sswig...@google.comwrote:
I'm working with David Levin, and based on the feedback received regarding
offscreen canvas, the proposal has been changed to address more specific
scenarios. The main use case was resizing images, so we are proposing an
asynchronous image resizing API. If you are curious about how we arrived at
our API below, take a look at the appendix to view the alternatives we
considered.
Let us know what you think. Thanks!
Sterling
Use Cases:
Begin with a user giving a local image file to a webpage. Then:
1. In real-time chat, quickly give other users a thumbnail view of the
image file.
2. Or, limit the size of an image file before uploading it to a web server.
This use case is already handled (minus the EXIF).
Proposed Solution:
We propose adding image.getBlob. getBlob will be an instance function of
the javascript Image object which asynchronously gets a blob of the image,
resized to the given width and height, encoded into jpeg or png. The
function declaration will be:
getBlob(mimeType /* req */, width /* req */, height /* req */, successEvent
/* req */, errorEvent /* op */, qualityLevel /* op */, preserveAspectRatio
/* op */, rotateExif /* op */);
The blob will be passed as an argument to the success callback function, or
upon error, error data will be passed into the error callback function as an
argument. Quality level should be between 0.0 and 1.0, and any value outside
of that range will be reverted to the default, 0.85. If MIME type does not
equal image/jpeg, then quality level is ignored. If null (or a negative
value) is passed in for the width or height, then the function will use the
source's measurement for that dimension. Default values for
preserveAspectRatio and rotateExif are true.
All EXIF metadata will be retained except for any saved thumbnails, and the
EXIF rotation property will be appropriately modified.
Security:
If the image source is of a different origin than the script context, then
getBlob raises a SECURITY_ERR exception.
Sample Code:
// url contains location of an image file
Image i = new Image();
i.src = url;
var successEvt = function (newBlob) { myDiv.innerHTML += img src=' +
newBlob.url + ' /; };
var errEvt = function (err) { alert(err); };
i.getBlob(image/jpeg, 300, 350, successEvt, errEvt, .55);
// Image will retain aspect ratio and correct for EXIF rotation. If the
source image was 700x700,
// the blob will represent a new image that is 300x300.
That's all!Appendix: Alternatives considered
For reference, we've also included a list of other designs that we thought
of along with the reasons why they were dropped
Creating a new object for resizing
Summary of approach:
[NamedConstructor=ImageResizer(),
NamedConstructor=ImageResizer(blob, onsuccess),
NamedConstructor=ImageResizer(blob, onsuccess, onerror),
NamedConstructor=ImageResizer(blob, onsuccess, onerror, type),
NamedConstructor=ImageResizer(blob, onsuccess, onerror, type, width,
height)]
interface ImageResizer {
void start(); // starts resize operation
void abort(); // aborts operation
attribute Blob blob;
attribute DOMString type; // default image/png
attribute unsigned long width;
attribute unsigned long height;
attribute float qualityLevel; // default 1.0, must be 0.0 to 1.0, else
reverts to default
readonly attribute unsigned short started; // default 0
attribute Function onsuccess;
attribute Function onerror;
};
Why it wasn't chosen:
Creating an entirely new object for this task made the task seem more
complicated and involved than necessary, and this problem could be solved
via modifications to the Image object.
Returning a SizelessBlob immediately from a method on image
Summary of approach:
var streamingBlob = image.toStreamingBlob(mimeType /* req */, width /* req
*/, height /* req */, qualityLevel /* op */, preserveAspectRatio /* op */,
rotateExif /* op */);
New Blob Interfaces:
interface SizelessBlob {
// moved from Blob
readonly attribute DOMString type;
readonly attribute DOMString url; // whatever name -- URL, urn, URN, etc.
}
interface StreamingBlob : SizelessBlob {
// at most one of the following functions will be called for a single
FutureBlob
attribute Function onblobready;
attribute Function onerror;
Re: [whatwg] Image resize API proposal
Thanks for your feedback Gregg. On Thu, May 13, 2010 at 3:32 PM, Gregg Tavares g...@google.com wrote: This really seems like the wrong solution. Taken to an extreme next you'll need to add VideoRisizer, AudioRecompresser, and any thing else JavaScript can't do without freezing the browser. It seems like it would be better to figure out a way to get Web Workers to be able to do this. This has been explored. See Alternatives considered in the original proposal. Even if they have to XHR the binary down, decompress into a TypeArray (see WebGL) and read the data themsevles so they can keep the EXIF stuff, bloating the browser for one small use doesn't seem like the right solution. Small use is a relative term. In that there are a lot of web properties that either do this or want to do this right now. You can post an open source library and the usage can be as simple as this proposal. Then you would have to include the open source library as part of your web application which is suboptimal. On Tue, May 11, 2010 at 11:58 AM, Sterling Swigart sswig...@google.comwrote: 2. Or, limit the size of an image file before uploading it to a web server. This use case is already handled (minus the EXIF). How? (Note limit the size. If you mean using canvas, it may hang the UI for the user which is a really bad experience. dave
Re: [whatwg] WebSockets: what to do when there are too many open connections
As an example from a bit different area, in Chrome the Web Workers today require a separate process per worker. It's not good to create too many processes so there is a relatively low limit per origin and higher total limit. Two limits help avoid situation when 1 bad page affects others. Once limit is reached, the worker objects are created but queued, on a theory that pages of the same origin could cooperate, while if a total limit is blown then hopefully it's a temporary condition. Not ideal but if there should be a limit we thought having 2 limits (origin/total) is better then have only a total one. On Thu, May 13, 2010 at 4:55 PM, Perry Smith pedz...@gmail.com wrote: On May 13, 2010, at 12:40 PM, Mike Shaver wrote: The question is whether you queue or give an error. When hitting the RFC-ish per-host connection limits, browsers queue additional requests from img or such, rather than erroring them out. Not sure that's the right model here, but I worry about how much boilerplate code there will need to be to retry the connection (asynchronously) to handle failures, and whether people will end up writing it or just hoping for the best. Ah. Thats a good question. (Maybe that was the original question.) Since web sockets is the topic and as far as I know web sockets are only used by javascript, I would prefer an error over queuing them up. I think javascript and browser facilities have what is needed to create its own retry mechanism if that is what a particular situation wants. I don't see driving the retry via a scripting language to be bad. Its not that hard and it won't happen that often. And it gives the javascript authors more control and choices. Thats my vote... pedz
[whatwg] The form attribute (Association of controls and forms)
Hi, 4.10.18 Association of controls and forms explains the link between forms and form-associated elements (and the form attribute). However, I've the feeling the specifications go far over what should be done and force the implementor how to do it. What I mean is, this could be summarized like this: If the form attribute is specified, the form owner of the element is the first form in the Document with the id corresponding of the form attribute value, if any. If the form attribute content is not a form element id, the element has no form owner. If the form attribute isn't specificed, the element form owner is the nearest ancestor form. However, the specification say (not only): When a form-associated element's ancestor chain changes, e.g. because it or one of its ancestors was inserted or removed from a Document, then the user agent must reset the form owner of that element. When a form-associated element's form attribute is added, removed, or has its value changed, then the user agent must reset the form owner of that element. When a form-associated element has a form attribute and the ID of any of the elements in the Document changes, then the user agent must reset the form owner of that form-associated element. When a form-associated element has a form attribute and an element with an ID is inserted into or removed from the Document, then the user agent must reset the form owner of that form-associated element. These sentences explain more than what should be the form owner but explain how to implement it. It seems useless and maybe not needed sometimes (I'm wondering if checking for the ID wouldn't be better than observing all the element's ID change and insertion/removal). In my opinion, the form attribute behaves more or less like the for attribute for the label element so I'm wondering why the specification is so different. Is there a reason I'm missing ? Thanks, -- Mounir
Re: [whatwg] WebSockets: what to do when there are too many open connections
I think that queuing in chrome bends the intent of the createWorker api just a little too far and will be happy to see it go away. I'd rather it failed outright then pretend to succeed when it really hasn't. (Actually that queuing code complicates the impl somewhat too... can you tell its been annoying me recently ;) On Thu, May 13, 2010 at 5:36 PM, Dmitry Titov dim...@chromium.org wrote: As an example from a bit different area, in Chrome the Web Workers today require a separate process per worker. It's not good to create too many processes so there is a relatively low limit per origin and higher total limit. Two limits help avoid situation when 1 bad page affects others. Once limit is reached, the worker objects are created but queued, on a theory that pages of the same origin could cooperate, while if a total limit is blown then hopefully it's a temporary condition. Not ideal but if there should be a limit we thought having 2 limits (origin/total) is better then have only a total one. On Thu, May 13, 2010 at 4:55 PM, Perry Smith pedz...@gmail.com wrote: On May 13, 2010, at 12:40 PM, Mike Shaver wrote: The question is whether you queue or give an error. When hitting the RFC-ish per-host connection limits, browsers queue additional requests from img or such, rather than erroring them out. Not sure that's the right model here, but I worry about how much boilerplate code there will need to be to retry the connection (asynchronously) to handle failures, and whether people will end up writing it or just hoping for the best. Ah. Thats a good question. (Maybe that was the original question.) Since web sockets is the topic and as far as I know web sockets are only used by javascript, I would prefer an error over queuing them up. I think javascript and browser facilities have what is needed to create its own retry mechanism if that is what a particular situation wants. I don't see driving the retry via a scripting language to be bad. Its not that hard and it won't happen that often. And it gives the javascript authors more control and choices. Thats my vote... pedz
Re: [whatwg] WebSockets: what to do when there are too many open connections
On 5/13/10 7:55 PM, Perry Smith wrote: Its not that hard and it won't happen that often. And it gives the javascript authors more control and choices. If a situation doesn't happen often, then historically speaking most authors will have no provisions to handle it. Try browsing the web with non-default colors set in your browser, with a default font size that's not 16px, or with a 13px minimum font size set. These aren't exactly hard things to deal with, but authors just don't deal with them. I sincerely doubt they'd deal with the possibility of a websocket not actually opening unless is was _very_ common. Maybe the spec should say that attempts to open a websocket should have a 50% chance of failing even if there's no good reason for it, just so it is in fact common for opening to fail? ;) (No, that's not a completely serious proposal, but it's not completely facetious either; it would take something like that for authors to handle failure properly.) -Boris
